Ύλη 2015 2016

Ξεκίνησε από GB, 07 Ιουν 2015, 09:07:35 ΠΜ

« προηγούμενο - επόμενο »

alpapanto

Και αν η Διαδικασία ΔΕΝ έχει στο σώμα των εντολών της ΓΡΑΨΕ ή ΔΙΑΒΑΣΕ, και υπολογίζει μια τιμή, πάλι δε θα μπορεί να κληθεί από μια Συνάρτηση;

Συμπέρασμα: Διδάσκουμε είτε συμφωνούμε είτε όχι, οτι σε καθε περίπτωση η Συνάρτηση ΔΕΝ καλεί Διαδικασία.

Αθανάσιος Πέρδος

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

Παράθεση από: alpapanto στις 13 Δεκ 2015, 06:10:52 ΜΜ
Συμπέρασμα: Διδάσκουμε είτε συμφωνούμε είτε όχι, οτι σε καθε περίπτωση η Συνάρτηση ΔΕΝ καλεί Διαδικασία.


dski

#212
Παράθεση από: Diotima στις 13 Δεκ 2015, 03:56:29 ΜΜ
Συμφωνώ απόλυτα. Όταν μια συνάρτηση Α καλεί μια άλλη συνάρτηση Β, στην ουσία δέχεται εσωτερικά ως είσοδο το αποτέλεσμα που επιστρέφει η Β.
Γιατί να μη μπορεί να το δέχεται από μια διαδικασία ή να δέχεται είσοδο από το χρήστη; Δεν κατανοώ τη διαφορά.

Ο κανόνας που αναφέρεται στο βιβλίο όσον αφορά την ανεξαρτησία των υποπρογραμμάτων είναι:
"Κάθε υποπρόγραμμα πρέπει να είναι ανεξάρτητο από τα άλλα. Αυτό σημαίνει ότι κάθε υποπρόγραμμα μπορεί να σχεδιαστεί, να αναπτυχθεί και να συντηρηθεί αυτόνομα χωρίς να επηρεαστούν άλλα υποπρογράμματα. Στην πράξη βέβαια η απόλυτη ανεξαρτησία είναι δύσκολο να επιτευχθεί."

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

Το θέμα ανάγεται στο πως κάνει την ανάλυση ο καθένας που γράφει το πρόγραμμα και αυτό είναι αρκετά υποκειμενικό θέμα και όπως λέει και το βιβλίο (σελ. 173):
"Η ανάλυση όμως αυτή δεν είναι πάντα εύκολη και όπως ισχύει γενικά στον προγραμματισμό, δεν υπάρχουν συγκεκριμένοι κανόνες για την επιτυχή ανάλυση."


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

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

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

gpapargi

#213
Παράθεση από: alpapanto στις 13 Δεκ 2015, 06:10:52 ΜΜ
Και αν η Διαδικασία ΔΕΝ έχει στο σώμα των εντολών της ΓΡΑΨΕ ή ΔΙΑΒΑΣΕ, και υπολογίζει μια τιμή, πάλι δε θα μπορεί να κληθεί από μια Συνάρτηση;

Θεωρητικά θα μπορούσε να επιτρέπεται η κλήση διαδικασίας από συνάρτηση υπό την προϋπόθεση  η διαδικασία να μην έχει μέσα της Γράψε/Διάβασε. Δε θα υπήρχε ασυνέπεια.
Θα υπήρχε κάποιο πρόβλημα από άποψη ανεξαρτησίας υποπρογραμμάτων. Σύμφωνα με αυτή, θα έπρεπε να μπορώ να χρησιμοποιήσω τη διαδικασία χωρίς να κοιτάξω εσωτερικά τον κώδικά της, δηλαδή το πώς είναι υλοποιημένη, παρά μόνο τις παραμέτρους της. Αν επιτρέπαμε επιλεκτικά την κλήση διαδικασίας (χωρίς Γράψε/Διάβασε)  από συνάρτηση, θα έπρεπε να κοιτάξουμε στο εσωτερικό της διαδικασίας για να δούμε αν τυχόν έχει ή δεν έχει Γράψε/Διάβασε. Και φαντάσου ότι μπορεί μια διαδικασία να καλεί άλλη διαδικασία, που καλεί άλλη διαδικασία και ούτω καθεξής. Σε αυτή την περίπτωση θα έπρεπε να κοιτάξουμε μέσα σε όλη την αλυσίδα διαδικασιών, να δούμε τον κώδικά τους και να ελέγξουμε αν υπάρχει  ή όχι στο βάθος εντολές Γράψε/Διάβασε. Αυτό δε θα ήταν καλό για την ανεξαρτησία των υποπρογραμμάτων.
Άρα νομίζω ότι δε θα ήταν πολύ καλή ιδέα τον να επιτρέπεται η κλήση διαδικασίας από συνάρτηση εκτός από την περίπτωση που η διαδικασίας έχει μέσα είσοδο/έξοδο.
Η άλλη εναλλακτική θα ήταν να επιτρέπονται όλα δηλαδή το να μπορεί η συνάρτηση να έχει απευθείας Γράψε/Διάβασε. Να επιτρέπονται δηλαδή τα πάντα. Αυτό αντίκειται στη λογική που θέλει τις συναρτήσεις να κάνουν απλώς υπολογισμούς και να επιστρέφουν μια τιμή. Θα ήταν πάντως συνεπής προσέγγιση και θα μπορούσε να υιοθετηθεί από την επιτροπή. Για μένα είναι καθαρά θέμα του τι συναρτήσεις θέλουμε. Αν τις θέλουμε να εκτυπώνουν μηνύματα και να δέχονται είσοδο με Διάβασε, τότε τα επιτρέπουμε όλα. Αν δεν το θέλουμε τότε τα κόβουμε όλα. Έγινε το δεύτερο. Θα μπορούσε να γίνει και το πρώτο.

pgrontas

#214
Το πιο σημαντικό χαρακτηριστικό της συνάρτησης κατά τη γνώμη μου είναι ότι μπορεί να χρησιμοποιηθεί στη θέση οποιασδήποτε σταθεράς, μεταβλητής, έκφρασης κτλ. όπως αναφέρεται και στο βιβλίο.
Αυτό συνεπάγεται ότι η συνάρτηση κάνει μόνο 1 πράγμα, όπως άλλωστε θα έπρεπε να ισχύει για όλα τα είδη υποπρογραμμάτων, αλλά εδώ δίνεται ιδιαίτερη έμφαση, καθώς θα αποτιμάται 'επί τόπου'. Άρα αυτό αποκλείει το ΔΙΑΒΑΣΕ/ΓΡΑΨΕ σε οποιαδήποτε αλυσίδα κλήσεων, όπως γράφει και ο Γιώργος, γιατί θα κάνει κάτι άλλο εκτός από το να υπολογίζει το αποτέλεσμα και μας ωθεί να έχουμε όσο το δυνατόν πιο σύντομες συναρτήσεις.

Επιπλέον το βλέπω και διαφορετικά: ΟΚ. Έχουμε ένα αμφισβητούμενο σημείο στο διδακτικό πακέτο. Πώς το χειριζόμαστε;

Λύση 1η:  Να προσκολληθούμε σε γλώσσες απαρχαιωμένες όπως αυτές που αναφέρονται στο διδακτικό πακέτο, επειδή αυτές ήταν δημοφιλείς όταν προγραμμάτιζαν οι συγγραφείς και να ακολουθήσουμε το τυπικό τους, ξεχνώντας όμως ότι οι γλώσσες προγραμματισμού είναι και εκφραστικά εργαλεία και δεν μας νοιάζει μόνο η ορθότητα.

Λύση 2η: Να την χειριστούμε δημιουργικά, εισάγοντας στοιχεία από τον τρόπο σκέψης άλλων γλωσσών, που καθορίζουν τον σύγχρονο τρόπο προγραμματισμού, με τον οποίο τελικά θα ασχοληθούν οι μαθητές, όπου οι συναρτήσεις αντιμετωπίζονται ως pure αντικείμενα των οποίων το αποτέλεσμα εξαρτάται από την είσοδό τους και μάλιστα με βάση αυτό μπορεί το πρόγραμμα να τύχει περαιτέρω ανάλυσης από τον compiler και να βρεθούν λάθη ή να εκτελεστεί παράλληλα ή ό,τι άλλο κάνουν οι συναρτησιακές γλώσσες.

Παιδαγωγικά, επιστημονικά και σε οποιονδήποτε τομέα μπορώ να σκεφθώ,  η δεύτερη λύση υπερέχει και κάθε άλλο παρά φιλολογική είναι, ούτε θα αναγκάσει τους μαθητές να ξεμάθουν πράγματα, γιατί 'άλλες' συναρτήσεις αυτές και 'άλλες' συναρτήσεις της C πχ. Αντίθετα δίνει μία νέα οπτική, η οποία αλλιώς δεν υπάρχει.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

alpapanto

Και κάτι ακόμη...
Πιθανό - απίθανο Σ-Λ στις εξετάσεις: Μια συνάρτηση μπορεί να καλέσει μια διαδικασία.

Οι μαθητές της Γ Λυκείου απαντουν: ΛΑΘΟΣ
Οι απόφοιτοι, που εξετάζονται με την περσινή ύλη, απαντούν ΣΩΣΤΟ

:D :D :D :Dκαι οι δυο είναι σωστοί :D :D :D :D

Αθανάσιος Πέρδος

Παράθεση από: pgrontas στις 14 Δεκ 2015, 05:17:49 ΜΜ
Λύση 1η:  Να προσκολληθούμε σε γλώσσες απαρχαιωμένες όπως αυτές που αναφέρονται στο διδακτικό πακέτο, επειδή αυτές ήταν δημοφιλείς όταν προγραμμάτιζαν οι συγγραφείς και να ακολουθήσουμε το τυπικό τους, ξεχνώντας όμως ότι οι γλώσσες προγραμματισμού είναι και εκφραστικά εργαλεία και δεν μας νοιάζει μόνο η ορθότητα.

Λύση 2η: Να την χειριστούμε δημιουργικά, εισάγοντας στοιχεία από τον τρόπο σκέψης άλλων γλωσσών, που καθορίζουν τον σύγχρονο τρόπο προγραμματισμού, με τον οποίο τελικά θα ασχοληθούν οι μαθητές, όπου οι συναρτήσεις αντιμετωπίζονται ως pure αντικείμενα των οποίων το αποτέλεσμα εξαρτάται από την είσοδό τους και μάλιστα με βάση αυτό μπορεί το πρόγραμμα να τύχει περαιτέρω ανάλυσης από τον compiler και να βρεθούν λάθη ή να εκτελεστεί παράλληλα ή ό,τι άλλο κάνουν οι συναρτησιακές γλώσσες.

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

Εντάξει η VB 2015 και η Delphi στις οποίες οι συναρτήσεις είναι διαδικασίες που επιστρέφουν μία τιμή δεν είναι απαρχαιωμένες γλώσσες. Δεν τις βλέπει έτσι η αγορά. Δεν δίνονται μισθοί 90000 δολλαρίων σε απαρχαιωμένους προγραμματιστές.

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

Το θέμα όμως είναι άλλο. Γιατί υιοθετούμε αυτή την προσέγγιση μετά από 15 χρόνια και την εφαρμόζουμε για δύο; Και μάλιστα με τον κίνδυνο να γελάνε μαζί μας αν βάλει θέματα κανένας περίεργος και δώσει το σωστό λάθος που έγραψε ο alpapanto σε προηγούμενο post.
Είναι τόσο μεγάλο το παιδαγωγικό όφελος ώστε να αξίζει τη φασαρία που θα προκαλούσε ένα τέτοιο θέμα εξετάσεων; 


pgrontas

Στο πρώτο διαφωνώ.
Αρχικά το βιβλίο δεν παρουσιάζει την VB2015 ούτε την Delphi, αλλά τους προγόνους τους της δεκαετίας του 80 με τον τρόπο σκέψης της εποχής. Επιπλέον οι προγραμματιστές COBOL είναι ακόμα πιο περιζήτητοι και καλοπληρωμένοι για migration legacy συστημάτων. Αυτό δεν σημαίνει ότι θα πρέπει να υιοθετήσουμε τον τρόπο σκέψης της.
Στο δεύτερο συμφωνώ και υπερθεματίζω ότι κακώς άργησε αυτή η επισήμανση.

Παράθεση από: Αθανάσιος Πέρδος στις 15 Δεκ 2015, 09:57:05 ΠΜ
Εντάξει η VB 2015 και η Delphi στις οποίες οι συναρτήσεις είναι διαδικασίες που επιστρέφουν μία τιμή δεν είναι απαρχαιωμένες γλώσσες. Δεν τις βλέπει έτσι η αγορά. Δεν δίνονται μισθοί 90000 δολλαρίων σε απαρχαιωμένους προγραμματιστές.

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

Το θέμα όμως είναι άλλο. Γιατί υιοθετούμε αυτή την προσέγγιση μετά από 15 χρόνια και την εφαρμόζουμε για δύο; Και μάλιστα με τον κίνδυνο να γελάνε μαζί μας αν βάλει θέματα κανένας περίεργος και δώσει το σωστό λάθος που έγραψε ο alpapanto σε προηγούμενο post.
Είναι τόσο μεγάλο το παιδαγωγικό όφελος ώστε να αξίζει τη φασαρία που θα προκαλούσε ένα τέτοιο θέμα εξετάσεων; 


Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

Αθανάσιος Πέρδος

Παράθεση από: pgrontas στις 15 Δεκ 2015, 12:05:48 ΜΜ
Στο πρώτο διαφωνώ.
Αρχικά το βιβλίο δεν παρουσιάζει την VB2015 ούτε την Delphi, αλλά τους προγόνους τους της δεκαετίας του 80 με τον τρόπο σκέψης της εποχής. Επιπλέον οι προγραμματιστές COBOL είναι ακόμα πιο περιζήτητοι και καλοπληρωμένοι για migration legacy συστημάτων. Αυτό δεν σημαίνει ότι θα πρέπει να υιοθετήσουμε τον τρόπο σκέψης της.
Όμως η Basic και η Pascal στο συγκεκριμένο θέμα έχουν τους ίδιους κανόνες με τις VB 2015 και τη Delphi. Απλά υπήρξε εξέλιξη ως προς τις δυνατότητες στις δύο τελευταίες. Ο τρόπος σκέψης στο συγκεκριμένο θέμα δεν άλλαξε. 

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

Γιατί λοιπόν τέτοια ευαισθησία να αλλάξει το συγκεκριμένο θέμα και να αναιρεθούν εκφράσεις από διαφορετικά σημεία του διδακτικού πακέτου τη συγκεκριμένη χρονική στιγμή; Μήπως η Python έχει διαδικασίες και συναρτήσεις όπως η ΓΛΩΣΣΑ και δεν θα υπάρχει συνέχεια;


pgrontas

Παράθεση από: Αθανάσιος Πέρδος στις 15 Δεκ 2015, 12:47:47 ΜΜ
Όμως η Basic και η Pascal στο συγκεκριμένο θέμα έχουν τους ίδιους κανόνες με τις VB 2015 και τη Delphi. Απλά υπήρξε εξέλιξη ως προς τις δυνατότητες στις δύο τελευταίες. Ο τρόπος σκέψης στο συγκεκριμένο θέμα δεν άλλαξε. 

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

Γιατί λοιπόν τέτοια ευαισθησία να αλλάξει το συγκεκριμένο θέμα και να αναιρεθούν εκφράσεις από διαφορετικά σημεία του διδακτικού πακέτου τη συγκεκριμένη χρονική στιγμή; Μήπως η Python έχει διαδικασίες και συναρτήσεις όπως η ΓΛΩΣΣΑ και δεν θα υπάρχει συνέχεια;


Σχετικά με το σχόλιο για την αλγοριθμική, εσύ αναφέρθηκες πρώτος σε συγκεκριμένες γλώσσες προγραμματισμού.
Σε κάθε περίπτωση, η δική μου τοποθέτηση αφορά το πώς έναν περιορισμό, με τον οποίο συμφωνώ για λόγους συνέπειας (χωρίς όμως καμία ευαισθησία), μπορούμε να τον χρησιμοποιήσουμε προς όφελος μας, δίνοντας μία νέα οπτική στους μαθητές.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

Diotima

Θανάση συμφωνώ σε όλα όσα γράφεις.
Οι ερωτήσεις που θέτεις είναι και δικές μου ερωτήσεις.

Κατανοώ επίσης ότι οι συγγραφείς όταν έγραψαν το διδακτικό πακέτο ανέλαβαν μια δύσκολη δουλειά. Πήραν ως πρότυπο τις υπαρκτές γλώσσες  Basic και Pascal, και περισσότερο κατά τη γνώμη μου την Pascal, και έφτιαξαν τη ΓΛΩΣΣΑ, κάνοντας όμως απλουστεύσεις ώστε η ΓΛΩΣΣΑ να συμβαδίζει με το σκοπό του μαθήματος που φανερά δεν ήταν η εκμάθηση μιας συγκεκριμένης γλώσσας προγραμματισμού αλλά η εισαγωγή του μαθητή στον αλγοριθμικό τρόπο σκέψης, στην Αλγοριθμική.
Δε γνωρίζω αν ήταν δική τους η απόφαση αυτών των απλουστεύσεων ή τους δόθηκε η οδηγία να το κάνουν, ήταν όμως δύσκολο έργο, γιατί κάποιος θα έπρεπε εξ' αρχής να σκεφτεί όλες τις πιθανές συνέπειες και ασυμβατότητες που μπορεί να προκύψουν από  αυτές τις απλουστεύσεις. Ο πιο ασφαλής τρόπος κατά τη γνώμη μου θα ήταν να διατηρηθούν όσα παρέμειναν στη ΓΛΩΣΣΑ όπως ακριβώς υπήρχαν π.χ. στην Pascal.
Τα πράγματα νομίζω θα ήταν έτσι εντελώς σαφή και συγκεκριμένα (με την επιφύλαξη ότι προσωπικά δεν έχω ερευνήσει σε βάθος αν μπορούσε να γίνει ακριβώς αυτό).

Κατανοώ επίσης και τη σύνδεση που κάνει το βιβλίο όσον αφορά τις συναρτήσεις της ΓΛΩΣΣΑΣ με τις μαθηματικές συναρτήσεις. Υπάρχει από πίσω ο παιδαγωγικός σκοπός να κατανοήσει ο μαθητής αυτόν τον τύπο υποπρογράμματος με βάση κάτι που του είναι γνωστό, να κάνει συνειρμούς, οπότε μπορεί να τον καταλάβει πιο εύκολα. Να μάθει το απλό υποπρόγραμμα με τη λογική της pure function και να προχωρήσει ομαλά στο διαφορετικό, πιο βαρύ  και πιο σύνθετο (διαδικασία).
Θα λέγαμε ότι παιδαγωγικά, από την άποψη της ευκολίας κατανόησης από τους μαθητές, είναι ο πιο ενδεδειγμένος τρόπος για τη διδασκαλία και τη χρήση συναρτήσεων στη ΓΛΩΣΣΑ.

Είναι άλλο όμως αυτό και άλλο η δημιουργία ενός αυστηρού κανόνα απαγόρευσης διότι:

Όταν στη φετινή έκδοση του βιβλίου (27-4-2015) διαβάζει ο μαθητής ή ο καθηγητής σε ακριβώς δύο συνεχόμενες σελίδες:

"Κάθε διαδικασία εκτελείται όταν καλείται από το κύριο πρόγραμμα ή άλλη διαδικασία." (σελ. 178)

και στην αμέσως επόμενη σελίδα:

"Κάθε διαδικασία ή συνάρτηση μπορεί να καλείται από το κύριο πρόγραμμα ή από άλλη διαδικασία ή συνάρτηση." (σελ.179)

και λαμβάνοντας υπ' όψη και όλες τις παραπομπές που παρέθεσε ο Θανάσης από τα σχολικά συγγράμματα,

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

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

Παρ' όλα αυτά θα ακολουθήσω αναγκαστικά την οδηγία που δόθηκε.

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

Kixer

#221
Καλησπέρα στο στέκι!

Θα ήθελα να ρωτήσω σχετικά με την ύλη των εσπερινών η οποία επανήλθε στα παλιά και με βάση αυτό:

http://www.ypepth.gr/publications/docs2015/101215_tropopoiisi_ylis.pdf

Δισδιάστατους πίνακες θα διδάξουμε φέτος στα παιδιά; Το κεφ. 9.3 είναι 'επιδεικτικά' εκτός ενώ το 3.3 είναι μέσα ολόκληρο. Από την άλλη οι οδηγίες που δόθηκαν (αντίστοιχες με αυτές των ΓΕΛ) δεν αναφέρουν πουθενά τη λέξη δισδιάστατος... Ωστόσο ασκήσεις με δισδιάστατους πάντα είχαν στα εσπερινά...

AEPP2106

Καλησπέρα σε όλους και χρόνια πολλά,

θα ήθελα να ρωτήσω αν έχετε να μου προτείνετε κάποιο βοήθημα το οποίο να έχει την καινούρια ύλη.

Ευχαριστώ!

Παντελης Τσιράκης

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

Rathaniel

Το στέκι δεν είναι χώρος διαφήμισης.
Μπορείς να στείλεις μέσω μηνύματος προσωπικού αυτό που διαφημίζεις (άθελα σου).
Χρηστίδης Αλέξανδρος,
Μηχανικός Επ/κών και Πλη/κών Συστημάτων,
Msc Στα Προηγμένα Συστήματα Πληροφορικής