Μια "αιρετική" αναζήτηση

Ξεκίνησε από gthal, 20 Ιαν 2011, 01:15:30 ΜΜ

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

itt

Παράθεση από: Νίκος Αδαμόπουλος στις 18 Φεβ 2014, 09:23:14 ΠΜ
Υ.Γ.

Σχετικά με την δημοτικότητα των γλωσσών προγραμματισμού:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

(Δες το υπότιτλο του άρθρου... Πολλές φορές τα πράγματα δεν είναι όπως τα νομίζουμε!)

To ΤΙΟΒΕ στηρίζεται σε search engine hits*, δεν είναι αντιπροσωπευτικό της χρήσης μιας γλώσσας (Ούτε απαραίτητα της δημοτικότητάς της). Εννοώ ότι θα μπορούσαν εκατομμύρια σελίδες να κράζουν την VB, παρόλα αυτά το index στο TIOBE θα αυξανόταν, επειδή ακριβώς συζητιέται.

* http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm

Νίκος Αδαμόπουλος

Έχουμε κάποιον άλλο καλύτερο δείκτη;

itt

Παράθεση από: Νίκος Αδαμόπουλος στις 18 Φεβ 2014, 06:32:16 ΜΜ
Έχουμε κάποιον άλλο καλύτερο δείκτη;

Όχι, γιατί κανένας δεν βγάζει νόημα. Το SO ας πούμε είναι αρκέτα biased ως προς την C#, αυτό δεν λέει τίποτα για την γλώσσα. Όπως επίσης δεν λέει τίποτα το ότι το subreddit της Haskell έχει πιο πολλούς χρήστες από αυτό της C#.   Γενικά δεν μπορείς να εκφράσεις μια μετρική που θα σου λύνει το πρόβλημα της δημοτικότητας εύκολα.

Σαφώς και η VB είναι σχετικά παραγκωνισμένη όταν έχεις C# + F# για να κάνεις τη δουλειά σου.



Νίκος Αδαμόπουλος

Παράθεση από: itt στις 18 Φεβ 2014, 07:41:32 ΜΜ
Σαφώς και η VB είναι σχετικά παραγκωνισμένη όταν έχεις C# + F# για να κάνεις τη δουλειά σου.

Ok. Άλλο όμως "σχετικά παραγκωνισμένη" και άλλο "παραγκωνισμένη έως ανύπαρκτη"...
Στην ουσία δεν αλλάζει τίποτα στη συζήτηση... Εγώ, όπως είπα, δεν είμαι υπέρ της διδασκαλίας κάποιας συγκεκριμένης γλώσσας...

thaaanos

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

itt

Παράθεση από: Νίκος Αδαμόπουλος στις 18 Φεβ 2014, 10:53:19 ΜΜ
Ok. Άλλο όμως "σχετικά παραγκωνισμένη" και άλλο "παραγκωνισμένη έως ανύπαρκτη"...
Στην ουσία δεν αλλάζει τίποτα στη συζήτηση... Εγώ, όπως είπα, δεν είμαι υπέρ της διδασκαλίας κάποιας συγκεκριμένης γλώσσας...

Συμφωνώ στο ότι δεν πρέπει να διδάσκεται συγκεκριμένη γλώσσα.

Παράθεση από: thaaanos στις 18 Φεβ 2014, 11:39:27 ΜΜ
Νομίζω οτι ξεφύγαμε... προσωπικά πιστεύω οτι η μερική αποτίμηση δεν είναι προγραμματιστικό τρικ. Είναι ένα ολόκληρο προγραμματιστικό παράδειγμα. Δεν γίνεται συναρτησιακός προγραμματισμός χωρίς μερική αποτίμηση.

Mια χαρά γίνεται, οι  Erlang , ML, Scala, F# είναι απλά παραδείγματα όπου δεν είναι το lazy evaluation η default προσέγγιση της γλώσσας.

thaaanos

Παράθεση από: itt στις 19 Φεβ 2014, 01:50:23 ΠΜ
Mια χαρά γίνεται, οι  Erlang , ML, Scala, F# είναι απλά παραδείγματα όπου δεν είναι το lazy evaluation η default προσέγγιση της γλώσσας.

Για το "μια χαρά" θα διαφωνήσω. Γίνεται specialization χωρίς partial evaluation;

P.Tsiotakis

Αρα 0*(1/0) κανει 0

Και βέβαια

Ψευδής και α[-5] = 3 κανει ψευδής


Και τελικα η γη κανει κυκλική ή ελλειπτικη τροχιά;;
Η αεππ ειναι εξεταζόμενο μάθημα;

pgrontas

Δηλαδή χρησιμοποιούμε τις λογικές συνθήκες για να ελέγξουμε αν οι μαθητές ξέρουν να σέβονται τα όρια του πίνακα ή τη διαίρεση με το 0;

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

Όμως, για μένα δεν πρέπει να είναι θεολογικό το θέμα, ώστε να προσπαθήσουμε να  προσαρμοστούμε στο θέσφατο του βιβλίου το οποίο δεν ξέρουμε σε τι συνθήκες γράφτηκε. Για παράδειγμα οι πρώτοι παράγραφοι του κεφάλαιου των δομών δεδομένων, μπορεί να διαπιστώσει εύκολα κανείς ότι αποτελούν αντιγραφή του κλασικού βιβλίου του Μανωλόπουλου που πολλοί κάναμε στο πανεπιστήμιο στη δεκαετία του 90. Είναι παιδαγωγικά ορθή η αντιγραφή πανεπιστημιακού υλικού για μαθητές δευτεροβάθμιας ή η δημιουργία βιβλίου με copy - paste;

Αυτό λοιπόν που πρέπει να μας απασχολήσει είναι η ουσία δηλ. αν κερδίζουμε κάτι επιτρέποντας τη  μερική αποτίμηση, ακόμα και αν δεν ορίζεται η δεύτερη έκφραση.  Οι σχεδιαστές γλωσσών προγραμματισμού, έχουν αποφανθεί ναι και έχει προκύψει το όλο ρεύμα με τις lazy evaluation γλώσσες, με τα πολλά πλεονεκτήματα (infinite streams, sequences). Φυσικά αυτό δεν αφορά κάποια super-duper γλώσσα του 2014, αλλά υπάρχει στην Lisp. Επιπλέον δεν είναι τεχνικό τό θέμα, αλλά καθαρά αλγοριθμικό γιατί δείχνει πώς κάποιοι χρησιμοποίησαν πρωτότυπα αυτόν τον όρισμό των λογικών πράξεων και έλυσαν προβλήματα ή εισήγαγαν νέες δυνατότητες. Αυτόγια μένα έχει διδακτική αξία.

Κλείνοντας νομίζω ότι τα παιδιά του λυκείου ξέρουν ότι η Γη έχει ελλειπτική τροχιά.
Programs must be written for people to read, and only incidentally for machines to execute - Harold Abelson

itt

Παράθεση από: thaaanos στις 19 Φεβ 2014, 12:22:50 ΜΜ
Για το "μια χαρά" θα διαφωνήσω. Γίνεται specialization χωρίς partial evaluation;

Το specialization είναι ένα optimization, δεν επηρρεάζει τα semantics της γλώσσας που χρησιμοποιείς. (Εκτός άμα εννοείς κάτι άλλο με το specialization) Ακόμα και tail elimination να μην έχεις, αυτό και πάλι δεν επηρρεάζει κάτι semantically.

Παράθεση από: Παναγιώτης Τσιωτάκης στις 19 Φεβ 2014, 01:27:01 ΜΜ

Και βέβαια

Ψευδής και α[-5] = 3 κανει ψευδής

Bασικά ναι

Α   Β   Α AND b
T   T        T
T   F        F
F   T        F
F   F        F
T   ⊥        ⊥
⊥   T        ⊥
F   ⊥        F
⊥   F        ⊥

Αλλά δεν διαφωνώ στο ότι δεν χρειάζεται να διδάσκεται.

thaaanos

#40
Σε επίπεδο software development, specialization, partial evaluation, επιτρέπουν design patterns και modularity.
Μην βλέπεις την αποτίμηση απλά σε μια αριθμητική έκφραση, φαντάσου εκφράσεις για τις οποίες η συγκεκριμένη συνάρτηση δεν έχει context για να αποτιμήσει.

Το call-by-name στην πραγματικότητα δεν είναι τίποτα άλλο παρά μασκαρεμένο partial evaluation.

Εγώ προσωπικά πιστεύω οτι τα διάφορα evaluation strategies πρέπει να διδάσκονται. Εάν δεν μιλήσουμε για την Eval() και την διαφορά έκφρασης και τιμής τότε γιατί θα πούμε;

itt

#41
Παράθεση από: thaaanos στις 19 Φεβ 2014, 07:08:54 ΜΜ
Σε επίπεδο software development, specialization, partial evaluation, επιτρέπουν design patterns και modularity.
Μην βλέπεις την αποτίμηση απλά σε μια αριθμητική έκφραση, φαντάσου εκφράσεις για τις οποίες η συγκεκριμένη συνάρτηση δεν έχει context για να αποτιμήσει.

Το call-by-name στην πραγματικότητα δεν είναι τίποτα άλλο παρά μασκαρεμένο partial evaluation.

Δεν διαφωνώ στη σημασία που έχει το evaluation stategy στην υλοποιήση διάφορων idioms. Αυτό  που λέω είναι ότι το αν είναι μια γλώσσα functional δεν καθόριζεται μόνο από το evaluation strategy που εφαρμόζει. Γενικά το από τι καθορίζεται είναι μια διαφωνία που ακόμα παίζει και δεν πιστεύω ότι θα υπάρξει ομοφωνία στο κοντινό μέλλον. Η Erlang πχ, είναι επιτυχημένη σε αυτό που κάνει, είναι referentially transparent et al. Αλλά είναι και strict. Δεν είναι functional; Δεν νομίζω.

Παράθεση από: thaaanos στις 19 Φεβ 2014, 07:08:54 ΜΜ
Εγώ προσωπικά πιστεύω οτι τα διάφορα evaluation strategies πρέπει να διδάσκονται. Εάν δεν μιλήσουμε για την Eval() και την διαφορά έκφρασης και τιμής τότε γιατί θα πούμε;

Noμίζω ότι είναι λίγο υπερβολικό να διδάσκονται. Μια χαρά μπορείς να διδάξεις αλγόριθμους χωρίς να θίξεις αυτό το θέμα.


Νίκος Αδαμόπουλος

Ξεχνάμε ότι έχουμε συγκεκριμένο βιβλίο για την ΑΕΠΠ, συγκεκριμένη ύλη που πρέπει να καλυφθεί, και συγκεκριμένο στόχο: να εξεταστούν οι μαθητές σε πανελλήνιες. Μην ξεχνάμε το πλαίσιο στο οποίο κινούμαστε... Βέβαια όταν το πλαίσιο αυτό αλλάξει (εύχομαι ποτέ!), και δεν θα υπάρχει το βαρίδι των εξετάσεων (!), θα έχουμε τη δυνατότητα να κάνουμε τους μαθητές πραγματικούς software developers...

petrosp13

Οι εξετάσεις δεν είναι βαρίδι, αλλά κίνητρο
Αν θεωρείτε ότι σε μάθημα που δεν εξετάζεται, θα αναπτύξετε software developers, νομίζω ότι θα διαψευστείτε από την πρώτη χρονιά κιόλας
Παπαδόπουλος Πέτρος
Καθηγητής Πληροφορικής

stpdt

#44
Παράθεση από: petrosp13 στις 19 Φεβ 2014, 11:42:45 ΜΜ
Οι εξετάσεις δεν είναι βαρίδι, αλλά κίνητρο
Αν θεωρείτε ότι σε μάθημα που δεν εξετάζεται, θα αναπτύξετε software developers, νομίζω ότι θα διαψευστείτε από την πρώτη χρονιά κιόλας

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

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

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

Στο μάθημά μου, φυσικά όταν αυτό δεν είναι το μάθημα πανελληνίων, και όταν το αναλυτικό πρόγραμμα μου δίνει την δυνατότητα, προσπαθώ να εξετάζω διαφορετικά.

Βάζω τους μαθητές να κάνουν "παραγγελίες" προγραμματων ο ένας στον άλλο, και βαθμολογώ με καλό βαθμό όσους μαθητές φέρουν είς πέρας τις "παραγγελίες", λαμβάνοντας υπόψη και τον βαθμό δυσκολίας της "παραγγελίας" (εκεί είναι η δική μου κρίση). Θεωρώ αυτή την προσέγγιση πιο κοντά στην πραγματικότητα του software development.