Ασκηση C

[defacer]

 

 

 

 

[gon1332]

Εγώ πάντως προτείνω αυτό.

[migf1]

Εγώ πάντως προτείνω αυτό.

 

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

 

Όπως και να 'χει, ας αφήσουμε και κάτι χρήσιμο στο νήμα, προτρέποντας όσους ξεκινούν προγραμματισμό (είτε για χόμπι, είτε για πιο σοβαρά) να μην επαναπαύονται στα επιφανειακά και βαρύγδουπα, αλλά να το ψάχνουν περισσότερο όσο και όταν μπορούν. Και να το ψάχνουν κατά προτίμηση με βιβλία (ηλεκτρονικά ή μη) και όχι σε φόρουμ.

 

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

 

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

[defacer]

Όπως και να 'χει, ας αφήσουμε και κάτι χρήσιμο στο νήμα, προτρέποντας όσους ξεκινούν προγραμματισμό (είτε για χόμπι, είτε για πιο σοβαρά) να μην επαναπαύονται στα επιφανειακά και βαρύγδουπα, αλλά να το ψάχνουν περισσότερο όσο και όταν μπορούν.

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

 

Πρώτον, cheers.

 

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

[gon1332]

 

Πρώτον, cheers.

 

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

 

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

[migf1]

Πρώτον, cheers.

 

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

 

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

 

MIT | Fall 2011 | Introduction to Algorithms : Algortithmic Thinking: Peak Finding

(όλως τυχαίως, έχει ως pre-requisit το μάθημα περί asymptotic analysis).

[Aztec]

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

 

Συγκεκριμένες ιδιαιτερότητες μιας γλώσσας όπως το memory allocation, memory leaks , pointers αποτελούν τροχοπέδη σε αυτό το πρώτο στάδιο. Πρέπει ο χρήστης να σκέφτεται παράλληλα με language specific έννοιες οι οποίες μπορεί και να τον αποθαρρύνουν.

[migf1]

Ακολουθεί σεντόνι (συγνώμη, αλλά το συγκεκριμένο τόπικ το θεωρώ εξαιρετικά σημαντικό για όσους ξεκινάνε να μαθαίνουν προγραμματισμό).

 

Θα συμφωνήσω με τον @defacer . Προσωπικά θεωρώ ότι η απόκτηση αλγοριθμική σκέψης , δηλαδή το σπάσιμο ενός προβλήματος σε μικρότερα προβλήματα και η ευχέρεια έκφρασης αυτών των προβλημάτων με κώδικα πρέπει αν γίνεται όσον το δυνατόν πιο αποδοτικά.

Αν το "αποδοτικά", στο οποίο καταλήγει η πρότασή σου, αντιστοιχεί στο κοινώς αντιληπτό efficiency ή αλλιώς complexity (είτε για ταχύτητα, είτε για πόρους) τότε δεν φαίνεται να συμφωνείς με τον defacer, αφού μας έχει ήδη διατρανώσει στο νήμα πως "η αλγοριθμική πολυπλοκότητα έχει τόση σχέση με την αλγοριθμική σκέψη όση έχει το νυχτερινό ρεύμα με το νυχτερινό σχολείο."... απαξιώνοντας μάλιστα να το "εξηγήσει για παιδάκια γιατί βαριέται". Οπότε δυστυχώς τα παιδάκια έχασαν μια σπάνια ευκαιρία να γίνουν καλύτεροι

 

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

Ένας που μαθαίνει προγραμματισμό, στο απλοϊκότατο παράδειγμα που ανέφερα στο νήμα (το να θέλει δηλαδή να κρατήσει ταξινομημένα real-time όπως έρχονται διάφορα elements) την επιλογή της δομής που θα χρησιμοποιήσει σε ποιο στάδιο της αλγοριθμικής σκέψης το εντάσεις σύμφωνα με όσα γράφεις στην παραπάνω παράγραφο; Εκτός αν συμφωνείς με τον defacer πως η δομή στο συγκεκριμένο παράδειγμα είναι ασήμαντη λεπτομέρεια ή ότι δεν άπτεται της αλγοριθμικής σκέψης, οπότε προφανώς δεν χρειάζεται περαιτέρω κουβέντα

 

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

 

Αν συμφωνούμε ότι πρέπει και να υλοποιήσει τον ψευδοκώδικα, τότε μήπως όταν φτάσει στην υλοποίηση, είναι (πολύ) πιθανό να "αναγκαστεί" να αναθεωρήσει την αρχική του αλγοριθμική σκέψη, επειδή θα διαπιστώσει πως τελικά στην πράξη το implementation matters;

 

Για να το πω με πιο απλά λόγια, μένοντας στο συγκεκριμένο παράδειγμα.

 

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

 

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

 

Μόνο που πλέον, αυτό αντιτίθεται στον εκφρασμένο του ψευδοκώδικα, οπότε πρέπει να πάει να τον αλλάξει (να γράψει δηλαδή πως θα προσθέτει στο τέλος και πως θα τυπώνει από το τέλος). Δηλαδή με άλλα λόγια, αναγκάζεται να αναθεωρήσει την αρχική αλγοριθμική του σκέψη.

 

Πάει τα αλλάζει, τα φτιάχνει όλα ωραία και καλά, κάνει και το απαραίτητο reallocation του πίνακά του κάθε φορά που εξαντλείται η χωρητικότητα της λίστας, προκειμένου να την αυξήσει και ξεκινάει το testing. Με λύπη του διαπιστώνει, πως μετά από ένα (μεγάλο) πλήθος elements στην είσοδο, το πρόγραμμά του είτε κρασάρει, είτε μπαίνει σε infinite loop, είτε προκαλεί major slow down.

 

Κοιτάει, ξανα-κοιτάει τον κώδικά του, ξανα κοιτάει τον ψευδικώδικά του... τίποτα... όλα μια χαρά.. δεν βρίσκει κάποιο λάθος. Το πρόβλημα όμως επιμένει στο run-time. Επειδή τώρα μαθαίνει, αλλά κυρίως επειδή του έχουν μάθει ότι δεν έχει και πολλή σημασία η υλοποίηση αρκεί να είναι σωστή η αλγοριθμική σκέψη, πάει σε έναν φίλο του χρόνια προγραμματιστή... το και το του λέει...

 

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

 

Όντως το αλλάζει και ω του θαύματος, το πρόγραμμά του όχι μόνο τρέχει τουλάχιστον το ίδιο γρήγορα κατά μέσο όρο, όχι μόνο καταναλώνει λιγότερη μνήμη κατά μέσο όρο, αλλά και χτυπάει κατά πολύυυυυυυυυυυυυυυυυυυυυυ (μα πάρα πολύυυυυυυυυ) αργότερα το memory barrier.

 

Συγκεκριμένες ιδιαιτερότητες μιας γλώσσας όπως το memory allocation, memory leaks , pointers αποτελούν τροχοπέδη σε αυτό το πρώτο στάδιο. Πρέπει ο χρήστης να σκέφτεται παράλληλα με language specific έννοιες οι οποίες μπορεί και να τον αποθαρρύνουν.

Το να ξέρει κανείς αν, ποιες δομές και γιατί τις χρησιμοποιήσει στην επίλυση του εκάστοτε προβλήματος, δεν είναι ιδιαιτερότητα της γλώσσας, αλλά στοιχειώδης αλγοριθμικός παράγοντας. Το να ξέρει και πώς και γιατί υλοποιείται η κάθε δομή είναι χρήσιμο έξτρα (συχνά όχι απαραίτητο όμως).

 

Το έγραψα και πριν, ξέρει κανείς κάποιο βιβλίο, μάθημα, κλπ για αλγόριθμους, που δεν ασχολείται ούτε με την πολυπλοκότητα ούτε με την υλοποίησή τους; Ή έστω να τα θεωρεί ανεξάρτητα το ένα από το άλλο ή ξένα προς την αλγοριθμική σκέψη;

[Aztec]

@migr

 

η θέση μου είναι συγκεκριμένη. Sorry αλλά δεν μπορώ να κάτσω να απαντήσω σε τόσο μεγάλο ποστ. Θεωρείς ότι οι pointers , τα memory leaks , το memory allocation ή και τα string ως char pointers βοηθάνε την αλγοριθμική σκέψη ? ή απλά περιπλέκουν συγκεκριμένα κομμάτια ενός αλγορίθμου. Δηλαδή θεωρείς πιο efficient χρονικά καποιος να ψαχνεται για memcopy και char pointers και να μην κάνει απλά εκχώρηση ενος string σε ένα άλλο? μια πιο restrictive γλώσσα δεν θα ήταν καλύτερη όσον αφορά την εξοικείωση με τον προγραμματισμό ? αν δεν το θεωρείς τότε εκεί είναι η διαφωνία μας και εκει θα έπρεπε να εστιάσουμε τον διάλογο.

 

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

[Timonkaipumpa]

@migr

 

η θέση μου είναι συγκεκριμένη. Sorry αλλά δεν μπορώ να κάτσω να απαντήσω σε τόσο μεγάλο ποστ. Θεωρείς ότι οι pointers , τα memory leaks , το memory allocation ή και τα string ως char pointers βοηθάνε την αλγοριθμική σκέψη ?

 

 

Ακριβώς αυτή είναι και δική μου ερώτηση. 

 

Και εγώ συμφωνώ με την θέση του defacer. 

 

Στα πρώτα στάδια (και όχι μόνο) του προγραμματισμού θεωρώ ως συμφέρον το να είναι black boxes οι διάφορες δομές. Χρησιμοποιείς ένα data structure έτοιμο για να μάθεις/χρησιμοποιήσεις τα προτερήματα και μειονεκτήματα της χρήσης του και όχι για να το υλοποιήσεις και να το βελτιστοποιήσεις εσύ. 

 

Σαφώς και δεν μειώνεται έτσι η σημασία και η σημαντικότητα των δεικτών αλλά με γλώσσες όπως ή Java και οι τελευταίες εκδόσεις της Objective C αυτή η γνώση (και για την δεύτερη στις περισσότερες εφαρμογές που δεν είναι DSP related) έχει αφεθεί σε όσους αναπτύσσουν frameworks και όχι σε όσους χρησιμοποιούν. 

 

Ένας νέο-εισερχόμενος δεν νομίζω ότι θα αποκομίσει κάτι εάν ασχοληθεί εξαρχής με την υλοποίηση ενός data-structure σε μία γλώσσα όπως η C αντί να ασχοληθεί με την χρήση της δομής σε μία γλώσσα όπως η Python ή η Java. Έτσι, η χρήση των δεικτών και η γνώση και διαχείριση της μνήμης δεν τον βοηθάει στα αρχικά στάδια. 

[imitheos]

Απέφυγα να πάρω μέρος μέχρι τώρα γιατί θα κατηγορούμουν ότι για άλλη μια φορά παίρνω το μέρος του defacer. Τώρα που λίγο ξεθύμανε το θέμα να πω ότι συμφωνώ με τον Timon και τον defacer. Δεν έχω διδάξει ποτέ βέβαια και δεν έχω εμπειρία πάνω στο θέμα αλλά αυτό που μου φαίνεται λογικό είναι να μην μπλέκουμε πολλές έννοιες μαζί σε αυτόν που μαθαίνει για να μπορεί να επικεντρωθεί σε ένα πράγμα.

 

Σκέψου ότι το πρώτο ποδήλατο που παίρνεις όταν είσαι 5-6-whatever χρόνων δεν έχει 18 ταχύτητες, συμπλέκτες και δεν ξέρω και εγώ τι άλλο. Επικεντρώνεσαι στο να μάθεις ισορροπία και όταν το μάθεις και συνηθίσεις, τότε μεταβαίνεις σε ποδήλατο με ταχύτητες.

 

Η ίδια λογική μου έρχεται και για τον προγραμματισμό. Είναι πιο εύκολο να μπεις σε ένα τρόπο σκέψης και να επικεντρωθείς στην σύλληψη του αλγορίθμου και την επίλυση του προβλήματος αν δεν χρειάζεται να μπλεχτείς με άλλες έννοιες όπως leaks, pointers, κτλ. Πόσες φορές δεν έχουμε γράψει ένα πρόγραμμα σε C και αντί να κάνουμε profiling να δούμε πως μπορεί να βελτιστοποιηθεί ο αλγόριθμος, κάνουμε debugging για να δούμε γιατί δεν παίζει σωστά κάποιος pointer ? Μάθε να σκέφτεσαι σωστά με τη χρήση μιας "εύκολης" γλώσσας και σε ένα μετέπειτα στάδιο κάτσε και μάθε και pointers και assembly και ό,τι άλλο χαμηλού επιπέδου θέλεις.

 

Όπως είπα και πριν βέβαια δεν έχω διδακτική εμπειρία οπότε μπορεί η λογική μου να είναι λανθασμένη. Κατά καιρούς διάφοροι πιο σοφοί από εμένα έχουν επιχειρηματολογήσει (πχ το άρθρο του Joel για τα Java schools) ότι αυτός ο τρόπος εκμάθησης δεν είναι σωστός και παράγει χάλια προγραμματιστές.

[defacer]

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

 

To point μου, και ο λόγος για τον οποίο ο παραλληλισμός που έκανα ίσως έχει κάποια ουσία, είναι ότι το ατύχημα που λες δεν συμβαίνει. Και δε συμβαίνει επειδή ο οδηγός ξέρει πότε πρέπει να τα αλλάξει (το λέει στο service manual) κι αν δεν ξέρει ρωτάει οποιονδήποτε πιο σχετικό (π.χ. συνεργείο) και μαθαίνει, έχοντας πιθανόν παρατηρήσει ότι τώρα τελευταία τα φρένα δεν πιάνουν τόσο καλά (ή ότι το πρόγραμμα αργεί όταν κάνει αναζήτηση).

 

Αντίστοιχα είναι πάρα μα πάρα πολύ απλό να διαβάσεις ή να ρωτήσεις και να σου πουν 2-3 πράγματα για κάποιες βασικές δομές δεδομένων (ούτε καν δε χρειάζεται να μάθεις τι είναι complexity) για να χρησιμοποιήσεις τη σωστή. Κι ακόμα και αυτό, χρειάζεται να το κάνεις μόνο εάν είσαι ερασιτέχνης (θεωρώ ότι ο επαγγελματίας οφείλει να γνωρίζει) και ταυτόχρονα έχεις να λύσεις ένα όχι και τόσο ερασιτεχνικό πρόβλημα. Γιατί αν έχεις να δουλέψεις με 500 ή με 40 records που είχα εγώ στον πρώτο "τηλεφωνικό κατάλογο" που έγραψα, ακόμα και να τους στείλεις με email σε άλλον για να στους κάνει sort πρόβλημα με την απόδοση δεν πρόκειται να έχεις.

 

Νομίζω ότι αυτά δεν πρέπει να εκπλήσσουν οποιονδήποτε διάβασε εκείνο το προηγούμενο post μου, απλά το κάνω λίγο πιο λιανά.

 

Όταν λέω "αλγοριθμική σκέψη" εννοώ "ο χρήστης γράφει έναν όρο αναζήτησης, και μετά για κάθε ένα χρήστη κοιτάμε να δούμε αν το όνομα ή το επώνυμο περιέχουν τον όρο αυτό". Στο στάδιο αυτό δε μας ενδιαφέρει ούτε με ποιά σειρά θα τους κοιτάξουμε, ούτε αν τους έχουμε σε πίνακα, λίστα, δέντρο ή σημειωμένους σ' ένα χαρτί στην τσέπη μας. Για την ακρίβεια, όταν θέλω να κάνω σε κάποιον εισαγωγή στην αλγοριθμική σκέψη δε χρησιμοποιώ καν οτιδήποτε έχει να κάνει με υπολογιστές, αλλά ξεκινάω από γνώριμα πράγματα όπως το κλασικό "σωκρατικό" "είμαι 6 χρονών και δεν ξέρω πώς να χρησιμοποιώ τον τηλεφωνικό κατάλογο, μάθε μου" ή "εξήγησέ μου πώς μπορείς πάντα να βρίσκεις τη σωστή απάντηση στο παιχνίδι μάντεψε τον αριθμό". Αυτή είναι η ουσία, όλα τα υπόλοιπα είναι implementation detail και απλά (σ' αυτό το πολύ αρχικό στάδιο) αποσπούν την προσοχή. Ή αν θες μια άλλη προσέγγιση, ο Aztec περιέγραψε με δικά του λόγια ακριβώς το ίδιο πράγμα.

 

Κατά καιρούς διάφοροι πιο σοφοί από εμένα έχουν επιχειρηματολογήσει (πχ το άρθρο του Joel για τα Java schools) ότι αυτός ο τρόπος εκμάθησης δεν είναι σωστός και παράγει χάλια προγραμματιστές.

 

Το άρθρο εκείνο όμως λέει κάτι ουσιωδώς διαφορετικό: ότι η κακή αυτή προσέγγιση περιλαμβάνει και την τελευταία πράξη "go forth and prosper as a programmer παρόλο που δεν ξέρεις τι είναι pointer". Πράγμα που και μένα κατ' ελάχιστο δε μου κάθεται καλά. Αλλά εδώ η θέση μου (μας?) είναι ότι δε χρειάζεται να ξέρεις τι είναι pointer μέχρι κάποιο σημείο Χ το οποίο έρχεται νωρίτερα από το να πάρεις το χρίσμα του προγραμματιστή.

[Directx]

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

 

Υπάρχουν περιπτώσεις που αν σε ενδιαφέρει η ταχύτητα πρέπει να κατέβεις πολύ χαμηλά, να ασχοληθείς βαθιά με θέματα χαμηλού επιπέδου, όχι μόνο διαχείριση μνήμης και pointers (αυτά είναι σχετικά απλά) αλλά και με λεπτομέρειες που αφορούν το ίδιο το λειτουργικό σύστημα για το οποίο γράφεις.

 

Αυτά τα γράφω μετ’ λόγου γνώσης -- κάποτε έγραψα μερικά προγράμματα (για Windows) που έπρεπε να είναι ελεεινά γρήγορα σε κρίσιμους τομείς – κάποια στιγμή λοιπόν έφτασα στα όρια των αλγόριθμων (και του compiler) και το υπόλοιπο optimization ήρθε από χαμηλότερα επίπεδα (διαχείριση μνήμης, GDI, λεπτομέρειες στην χρήση των Window controls κλπ) με θεαματικά αποτελέσματα.

 

Ευτυχώς όμως στις περισσότερες περιπτώσεις (και για την πλειοψηφία των λογισμικών) κάτι τέτοιο δεν είναι απαραίτητο.

 

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

[migf1]

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

 

Από ότι καταλαβαίνω από τις τελευταίες δημοσιεύσεις (aztec, timon και imitheos) μάλλον έχω δώσει την εντύπωση πώς συνιστώ στους νέους να παλεύουν μόνοι τους με τα memory leaks, με χειροκίνητα garbage collections, με dangling pointers hunting, κλπ. Κάτι τέτοιο σαφώς και ΔΕΝ ισχύει.

 

Νόμιζα πως το παράδειγμα που ανέπτυξα ήταν σαφές, αλλά κρίνοντας από τις τελευταίες δημοσιεύσεις έχω πλέον βάσιμες αμφιβολίες. Δηλαδή, θεωρείτε πως προτείνω στους αρχάριους να υλοποιήσουν ντε και καλά μόνοι τους τον πίνακα ή την linked list του παραδείγματός μου (μαζί με τα operations τους);

 

Αν ναι, τότε στο παράδειγμά μου αντικαταστήστε όπου "πίνακας" την έτοιμη υλοποιημένη ArrayList κλάση στη Java, και όπου "linked list" την έτοιμη υλοποιημένη κλάση LinkedList στη Java. Επομένως, ο ήρωάς μας δεν θα ασχοληθεί καθόλου με την υλοποίηση της δομής, θα έχει και έτοιμη και την ρουτίνα εισαγωγής, αλλά θα εξακολουθεί όμως να πρέπει να υλοποιήσει τον ψευδοκώδικά του επιλέγοντας κάποια από τις έτοιμες, υλοποιημένες δομές/κλάσεις.

 

Επιλέγοντας την έτοιμη ArrayList, θα έχει τα ίδια προβλήματα που περιγράφω στο προηγούμενο ποστ μου. Ο φίλος του, θα του προτείνει να χρησιμοποιήσει την έτοιμη LinkedList, με τα ίδια ευεργετικά αποτελέσματα που περιγράφω στο προηγούμενο ποστ μου.

 

Άρα, το θέμα μας εδώ δεν είναι το αν θα υλοποιήσει μόνος του τις δομές ή αν θα τις πάρει έτοιμες, αλλά το αν η αλγοριθμική σκέψη περιλαμβάνει ή όχι την γνώση βασικών έστω εννοιών περί αποδοτικότητας και υλοποίησης (αυτά τα 2 καλώς ή κακώς πάνε μαζί μέχρι έναν βαθμό). Για αυτό και σε κάποιο προηγούμενο ποστ μου έγραψα πως η γλώσσα δεν έχει σημασία.

 

Τέλος, τον ορισμό της αλγοριθμικής σκέψης σαφώς και τον εστιάζω στον προγραμματισμό, αφού για προγραμματισμό μιλάμε. Παρόλο που δεν υπάρχει επίσημος ορισμός της "αλγοριθμικής σκέψης", το μόνο σίγουρο είναι πως όλα τα διδακτικά μέσα περί αλγορίθμων από την αρχή μέχρι και σήμερα περιλαμβάνουν ΑΠΑΡΑΙΤΗΤΑ δομές, αποδοτικότητα και υλοποίηση.

 

Σε ότι αφορά τους δείκτες, όπως έγραψα εξαρχής, είναι ένα έξτρα (όχι δηλαδή πάντα απαρίτητο) το οποίο όμως δύναται να διευκολύνει όποιον μαθαίνει να κατανοήσει καλύτερα ή πιο γρήγορα τα υπέρ και τα κατά των δομών που έχει στη διάθεσή του (είτε θέλει να τις υλοποιήσει μόνος του είτε να τις πάρει έτοιμες).

[defacer]

Από ότι καταλαβαίνω από τις τελευταίες δημοσιεύσεις (aztec, timon και imitheos) μάλλον έχω δώσει την εντύπωση πώς συνιστώ στους νέους να παλεύουν μόνοι τους με τα memory leaks, με χειροκίνητα garbage collections, με dangling pointers hunting, κλπ. Κάτι τέτοιο σαφώς και ΔΕΝ ισχύει.

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

 

Τέλος, τον ορισμό της αλγοριθμικής σκέψης σαφώς και τον εστιάζω στον προγραμματισμό, αφού για προγραμματισμό μιλάμε. Παρόλο που δεν υπάρχει επίσημος ορισμός της "αλγοριθμικής σκέψης", το μόνο σίγουρο είναι πως όλα τα διδακτικά μέσα περί αλγορίθμων από την αρχή μέχρι και σήμερα περιλαμβάνουν ΑΠΑΡΑΙΤΗΤΑ δομές, αποδοτικότητα και υλοποίηση.

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

 

Σε ότι αφορά τους δείκτες, όπως έγραψα εξαρχής, είναι ένα έξτρα (όχι δηλαδή πάντα απαρίτητο) το οποίο όμως δύναται να διευκολύνει όποιον μαθαίνει να κατανοήσει καλύτερα ή πιο γρήγορα τα υπέρ και τα κατά των δομών που έχει στη διάθεσή του.

Επίσης όμως "δύναται" και να κάνει ακριβώς το αντίθετο από το να διευκολύνει. Αν το "δύναται" το εννοείς με την έννοια του λεξικού "υπάρχει non-zero chance να συμβεί" τότε νομίζω ότι αυτή η τοποθέτηση απέχει πάρα πολύ από το να χαρακτηριστεί πειστικό επιχείρημα. Αν το εννοείς με άλλη έννοια, ποιά είναι αυτή;

 

Επίσης, δεν ξέρω πώς εννοείς το "έξτρα" αλλά επειδή μιλάμε για τη C, νομίζω πως όλοι σ' αυτό το thread συμφωνούμε πως οι pointers είναι κάθε άλλο παρά έξτρα με το οποίο αν θες δεν ασχολείσαι.

switch(playerName) {
    case "mitsos": // που να στα λέω τώρα...
}