Γιατί θα χρειαζόμαστε πάντα νέες γλώσσες προγραμματισμού

Δομή και ερμηνεία των προγραμμάτων υπολογιστών από τους Harold Abelson και Gerald Jay Sussman είναι ένα από τα καλύτερα βιβλία για τον προγραμματισμό που γράφτηκε ποτέ. Ήταν μπροστά από την εποχή του για πολλά χρόνια.

Τα πλεονεκτήματα του λειτουργικού προγραμματισμού που επισημάνθηκαν εξακολουθούν να αποτελούν μια συνεχή πηγή έμπνευσης για ομιλητές, καθηγητές και άλλους συγγραφείς. Έδειξε τη δύναμη και τα μειονεκτήματα του αντικειμενοστρεφούς προγραμματισμού όταν ήταν ακόμη νέος. Οι δυνάμεις διαφημίζονται γρήγορα χάρη στους αντικειμενικούς φανατικούς προγραμματισμού. Από την άλλη πλευρά, χρειάστηκαν χρόνια για να δει η κοινότητα τα ελαττώματα.

Το τελευταίο κεφάλαιο αφιερώθηκε εξ ολοκλήρου σε μια άλλη ιδέα που δεν συζητείται ακόμη πολύ στον λαϊκό διάλογο: την ανάγκη για νέες γλώσσες προγραμματισμού. Παρόλο που το βιβλίο συμπάθει με τον Lisp, ισχυρίστηκε σαφώς ότι δεν είναι η τελική γλώσσα προγραμματισμού. Καμία γλώσσα δεν θα είναι ποτέ.

Θα χρειαζόμαστε πάντα νέες γλώσσες προγραμματισμού για να βελτιώσουμε την εκφραστικότητα μας. Αυτή δεν είναι μια ασήμαντη δήλωση, και για να καταλάβουμε τι κρύβεται πίσω από αυτό, πρέπει να κατεβούμε δύο επίπεδα.

Τι είναι η γλώσσα προγραμματισμού;

Δείτε την ακόλουθη λειτουργία:

fun square(a: Int) = a * a
// Usageprint(square(10) + square(20))

Τι σημαίνει αυτό που squareορίζεται;

Από τεχνική άποψη, είναι απλώς μια απλοποίηση και το σώμα μπορεί να αντικαταστήσει όλες τις κλήσεις:

// Kotlinprint(10 * 10 + 20 * 20)

Από την άποψη του προγραμματιστή, squareείναι πολύ περισσότερο. Το γεγονός ότι μπορούμε να ορίσουμε μια τέτοια συνάρτηση δεν είναι μόνο ένας απλούστερος τρόπος για να κάνουμε μια λειτουργία, αλλά και μας επιτρέπει να εκφράσουμε μια έννοια τετραγώνου. Αυτή η συνάρτηση είναι κάποια αφαίρεση.

Αν ήταν πιο περίπλοκο, θα μας επέτρεπε να κρύψουμε όλη αυτή την πολυπλοκότητα πίσω από μια απλή κλήση λειτουργίας. Αυτό είναι ο προγραμματισμός: Διαφορετικές δυνατότητες γλώσσας προγραμματισμού μας επιτρέπουν να εκφράζουμε πράγματα με διαφορετικούς τρόπους.

Εξέλιξη γλωσσών προγραμματισμού

Η βιομηχανία προγραμματισμού εξελίσσεται και έτσι γίνονται και οι γλώσσες προγραμματισμού. Σκεφτείτε το for-loop. Αρχικά, υπήρχε μόνο ένας βρόχος όταν.

Σύντομα οι προγραμματιστές παρατήρησαν ένα κοινό μοτίβο:

// Cint i = 0;while(i < n) { i++; // ...} 

Η whileέκφραση χρησιμοποιήθηκε ξανά και ξανά για να επαναλάβει κάτι - κυρίως αριθμούς, διευθύνσεις ή επαναλήψεις.

Έτσι, παρουσιάσαμε το for-loop:

// C++for (int i = 0; i < n; i++) { // ...}

Σύντομα η βιομηχανία παρατήρησε ότι το for-loop χρησιμοποιείται κυρίως για την επανάληψη στοιχείων από μια λίστα.

Αυτός είναι ο λόγος για τον οποίο οι γλώσσες εισήγαγαν μια νέα παραλλαγή του for-loop που έχει σχεδιαστεί για επανάληψη list:

// Kotlinfor(e in list) { // ...}

Χρειαζόμαστε λοιπόν νέες δυνατότητες

Αλλά οι γλώσσες εξελίσσονται, γιατί να μην κολλήσουν μαζί τους;

Είναι αλήθεια ότι οι γλώσσες εξελίσσονται. Σε ορισμένες περιπτώσεις, είναι πραγματικά εντυπωσιακό πώς οι παλιές γλώσσες όπως C ++, Java ή JavaScript μπορούν να έχουν καλή υποστήριξη για λειτουργικά στοιχεία προγραμματισμού για τα οποία δεν είχαν σχεδιαστεί. Αλλά το πρόβλημα είναι ότι οι νέες δυνατότητες δεν αντικαθιστούν τις παλιές - αλλά προστίθενται.

Όσον αφορά τις δυνατότητες γλώσσας προγραμματισμού, τα περισσότερα δεν είναι απαραίτητα καλύτερα. Είναι μπερδεμένο όταν μπορούμε να εκφράσουμε την ίδια έννοια με πολλούς διαφορετικούς τρόπους.

Σκεφτείτε τη Σκάλα. Η μεγαλύτερη αντίρρηση με το Scala είναι ότι πάρα πολλά διαφορετικά χαρακτηριστικά καθιστούν εξαιρετικά δύσκολο να κατανοήσουμε τι συμβαίνει στον κώδικα ενός προγραμματιστή με λίγη υπερβολική δημιουργικότητα.

Η γλώσσα προγραμματισμού Go βασίστηκε στη δημοτικότητά της με απλότητα. Δεν πρόκειται για πόσες δυνατότητες έχουν ορισμένες γλώσσες, αλλά για το να έχετε το τέλειο σύνολο δυνατοτήτων.

Κατά τη γνώμη μου, αυτός είναι ο λόγος για τον οποίο όλοι αγαπούν τόσο πολύ τον Kotlin. Είναι η πιο καλά σχεδιασμένη γλώσσα προγραμματισμού που ξέρω.

Υπάρχουν ισχυροί λόγοι για αυτό:

  • Ήταν σε beta για 6 χρόνια και εξελίχθηκε επαναληπτικά καθ 'όλη τη διάρκεια του χρόνου
  • Έχει σχεδιαστεί από την JetBrains που έχουν καταφέρει να κατανοήσουν τις γλώσσες προγραμματισμού και πώς χρησιμοποιούν οι άνθρωποι εδώ και χρόνια

Κατά τη διάρκεια της περιόδου beta, υπήρχαν ορισμένες σημαντικές λειτουργίες που εφαρμόστηκαν πλήρως, και όμως καταργήθηκαν πριν από το 1.0. Μεταξύ αυτών είναι πλειάδες. Ο Κότλιν τους υποστήριξε πλήρως! Ωστόσο, η ομάδα του Kotlin κατάργησε την υποστήριξη για πλειάδες πριν από το Kotlin 1.0 επειδή η ανάλυση και τα πειράματά τους έδειξαν ότι οι πλειάδες κάνουν περισσότερο κακό παρά καλό, και οι άνθρωποι θα πρέπει να χρησιμοποιούν τάξεις δεδομένων. Αυτό δείχνει ότι το JetBrains κατανοεί τη σημασία του καλού σχεδιασμού.

Μια άλλη γλώσσα που είναι καλά σχεδιασμένη είναι η Swift. Αναπτύχθηκε πολύ πιο γρήγορα και οι προγραμματιστές που το σχεδίασαν έκαναν πολλά λάθη. Ωστόσο, η Apple άλλαξε το σχέδιο με σχεδόν κάθε μεγάλη έκδοση. Δεν ενδιαφέρονται πραγματικά για την κληρονομιά.

Οι προγραμματιστές γκρινιάζουν, αλλά από την άποψη του σχεδιασμού, είναι υπέροχο. Αν και δεν μπορούν να συνεχίσουν να το κάνουν για πολύ. Όσο περισσότερα πράγματα υπάρχουν στο Swift, τόσο μεγαλύτερο είναι το κόστος αλλαγής σχεδιασμού. Επίσης, δεν νομίζω ότι μπορούν να αλλάξουν σημαντικές λειτουργίες.

Αν λοιπόν έχουμε καλά σχεδιασμένες νέες γλώσσες, είναι οι τελικές γλώσσες;

Καθόλου. Οι βιομηχανίες εξελίσσονται. Η σκέψη μας εξελίσσεται. Και έτσι οι γλώσσες προγραμματισμού πρέπει να εξελιχθούν επίσης.

Ένα πράγμα είναι ότι θα δημιουργηθούν ιδέες για νέα χαρακτηριστικά και τρόπους σκέψης, και οι τέλεια σχεδιασμένες γλώσσες δεν θα είναι πλέον τέλειες.

Το δεύτερο είναι ότι μαθαίνουμε περισσότερα για τον προγραμματισμό. Οι τάξεις και οι μέθοδοι είναι ανοιχτές από προεπιλογή στην Java. Ο Kotlin τους έκανε και τους δύο τελικούς από προεπιλογή, επειδή οι προγραμματιστές χρησιμοποιούν πολύ κληρονομιά όταν δεν έπρεπε.

Τα μέλη της κλάσης Java ήταν από προεπιλογή πακέτο. Αυτός ο τροποποιητής σχεδόν ποτέ δεν χρησιμοποιήθηκε. Το Kotlin δεν το επιτρέπει καθόλου, αλλά τα μέλη της τάξης είναι δημόσια από προεπιλογή, επειδή αυτός είναι ο πιο κοινός τροποποιητής για αυτά. Αλλάζουμε τις συνήθειες μας και μαθαίνουμε, έτσι και οι γλώσσες πρέπει να αλλάξουν μαζί μας.

Το τρίτο πράγμα είναι ότι τα πρότυπα αλλάζουν. Βλέπω τη στασιμότητα όσον αφορά τα παραδείγματα προγραμματισμού, αλλά έχουμε ακόμη κάποια να εισαγάγουμε στην καθημερινή πρακτική.

Πού πήγε ο λογικός προγραμματισμός; Σημειώστε ότι μπορείτε να χρησιμοποιήσετε αυτό το παράδειγμα και απλώς να παρέχετε ένα σύνολο περιορισμών για έναν ιστότοπο και να περιμένετε ότι ο ιστότοπος θα δημιουργηθεί αυτόματα βάσει αυτών. Είναι δυνατόν να εφαρμοστεί αυτό. Επίσης, σύντομα ή γρήγορα θα γεννηθούν νέα πρότυπα. Δεν μπορεί να έχει εξερευνήσει τα πάντα.

Τέλος, γεννιούνται νέες τεχνολογίες και ο παλιός τρόπος σκέψης που αντιπροσωπεύεται από τις προηγούμενες γλώσσες μπορεί να μην είναι επαρκής.

Σκεφτείτε το blockchain. Όταν μιλάω με άτομα που σκέφτονται να αλλάξουν, θέλουν να χρησιμοποιήσουν τις αγαπημένες τους γλώσσες όπως Java ή JavaScript. Αν και όταν μιλάω με προγραμματιστές blockchain, ισχυρίζονται ότι το blockchain πρέπει να αναπτυχθεί σε γλώσσες που έχουν σχεδιαστεί για αυτό.

Για παράδειγμα, μια σύμβαση είναι μια έννοια που δεν έχει ισοδύναμο στον προγραμματισμό. Μπορεί να προσομοιωθεί ανά τάξη, αλλά αυτό είναι επιβλαβές για τον τρόπο που το σκέφτονται οι άνθρωποι. Είναι καταστροφικό όταν προσπαθούμε να εκφράσουμε νέα πράγματα χρησιμοποιώντας παλιές λέξεις. Είναι σαν να ονομάζουμε ένα αυτοκίνητο από χάλυβα άλογο και να προσπαθούμε να κάνουμε μηχανικούς από κτηνίατρους.

Κλείσιμο

Σκεφτείτε τα μαθηματικά. Η ισορροπία μπορεί να εκφραστεί με περιγραφικό τρόπο:

Δύο συν τρία ισούται με πέντε

Αν και είναι κάτι εντελώς διαφορετικό από το να το εκφράζουμε χρησιμοποιώντας τη μαθηματική σημειογραφία:

2 + 3 = 5

Δεν είναι η μόνη βελτιστοποίηση για αναγνωσιμότητα και χώρο. Αυτές οι δύο συμβολές σημαίνουν το ίδιο πράγμα, αλλά αντιπροσωπεύουν εντελώς διαφορετικές έννοιες. Αυτό είναι κάτι που δεν είναι σημαντικό από την άποψη του υπολογιστή - το οποίο μπορεί εύκολα να μεταφράσει την περιγραφική μορφή σε μαθηματικά - αλλά είναι το πιο σημαντικό πράγμα για εμάς ως ανθρώπους.

Εάν δεν ήταν σημαντικό, θα λειτουργούσαμε σε Assembler αντί για Java, JavaScript, Python ή Kotlin. Αλλά είναι σημαντικό. Γι 'αυτό χρειαζόμαστε καλύτερη και καλύτερη έκφραση και χρειαζόμαστε νέες γλώσσες προγραμματισμού.

Σχετικά με τον Συγγραφέα

Ο Marcin Moskała (@marcinmoskala) είναι εκπαιδευτής και σύμβουλος, επί του παρόντος επικεντρώνεται στην παροχή Kotlin σε Android και σε προχωρημένα εργαστήρια Kotlin (για περισσότερες λεπτομέρειες, υποβάλετε αίτηση εδώ). Είναι επίσης ομιλητής, συγγραφέας άρθρων και ένα βιβλίο για την ανάπτυξη Android στο Kotlin.