περιεργος καθηγητής;

[Dinos_12345]

@defacer δεν κάνω quote το κατεβατό.

Συμφωνώ απόλυτα, απλά δεν μπορούσες να το θέσεις καλύτερα. Απλά νομίζει ότι ξέρει, και λέει ότι είναι tester. Λέει κάποια σωστά πράγματα και φαίνεται sophisticated, όμως έχει πολλά θέματα. Μου είπε το εξής, "και ο κακομοίρης ο tester που θα κοιτάζει τον κώδικα σου στις 2 το πρωί τι χρωστάει να σκαλώνει όταν δει το break;"

Και "είναι σα να παίρνεις κοτόπουλο σε νηστεία και να το λες αρακά για να μην αμαρτήσεις, όπως το goto είναι με το break"

Άλλο ένα μάθημα έμεινε μαζί του ευτυχώς, γιατί τα νεύρα μου τα κάνει λάστιχο.

 

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

[GReaperEx]

"είναι σα να παίρνεις κοτόπουλο σε νηστεία και να το λες αρακά για να μην αμαρτήσεις, όπως το goto είναι με το break"

 

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

 

Μη με παρεξηγήσετε, η χρήση του goto μπορεί πολύ εύκολα να δημιουργήσει μακαρονάδα στα χέρια ενός άπειρου. Αλλά οτιδήποτε μπορεί να μακαρονοποιηθεί στα χέρια πρωτάρηδων. Πιστέψτε με, δεν υπάρχει ακόμα αυτή η εντολή στη C και στη C++ μόνο για backward compatibility.

[Kercyn]

Πριν κάτι μήνες είχε βάλει κάποιος ένα github ενός συστήματος για edge detection σε ρομπότ ή κάτι τέτοιο, το οποίο παίζει να ήταν τέρμα optimized και είχε πυραμίδες από goto βάθους περίπου 15 στηλών, και αυτό για 500 γραμμές. Έκανες scroll και ήταν σα να βλέπεις κάθετα κύματα.

[najinblue3]

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

 

Στην πολυπλοκότητα αυτός που είχαμε είχε πολύ ειρωνικό ύφος, φάση άσε δεν ξέρεις σου λέω και έλεγε ατάκες τύπου "welcome to computer science" όταν έβαζε δύσκολο πρόβλημα. Είναι σπαστικό. Έχω καθηγητή που δεν βάζει το int μπροστά στη main στη c, και στο compile βγάζει 20 warnings για invalid casts σε pointers.

Συμφωνω, ειδικα Θεωρητικοι, εγω εχω τωρα μαθημα στη σχολη μου advanced algorithms με τυπο ο οποιος παιζει να μην καταλαβεις οτι ειναι καθηγητης, πολυ προσιτος, μιλαει πολυ και εξηγει οτι δε καταλαβαινω / καταλαβαινουμε, που ειναι πολλα 

 

Στην Ελλαδα σε Αλγοριθμους και δομες, καθηγηταρας δεν εκανε καν στον κοπο να εξηγησει βασικα πραματα που οταν τα βλεπεις πρωτη φορα απλα δεν, και μας παρεπεμπε στο Wiki

 

Αυτο που λες για βιογραφικο, σαν Θεωρητικος στο Computer science η δουλεια σου ειναι το research, κυριως σε αλγοριθμους καινουργιους 2000+, τουλαχιστον απο τη σχολη μου αυτο ξερω, γι αυτο και οι περισσοτεροι κυνηγανε καριερα σε σχολες κτλπ, τους περισσοτερους δεν τους ενδιαφερει να αναζητησουν δουλεια εξω απο σχολες, παρα να μεινουν και να συνεχισουν το research / teaching

[Ilias95]

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

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

Πριν κάτι μήνες είχε βάλει κάποιος ένα github ενός συστήματος για edge detection σε ρομπότ ή κάτι τέτοιο, το οποίο παίζει να ήταν τέρμα optimized και είχε πυραμίδες από goto βάθους περίπου 15 στηλών, και αυτό για 500 γραμμές. Έκανες scroll και ήταν σα να βλέπεις κάθετα κύματα.

link please?

[imitheos]

Και είπε σήμερα το εξής:

for(int i=0; i<N && !found; i++){
  if(a[i] == element){
    found = TRUE;
  }
}

Είναι καλύτερο και πιο κατανοητό από

for(int i=0; i<N; i++){
  if(a[i] == element){
    found = TRUE;
    break;
  }
}

 

[troll]

for(int i=0; i<N && !found; i++){
  found = a[i] == element;
}

Πες του ότι έτσι γλυτώνουμε το nesting level του if οπότε ο "tester" θα καταλάβει ακόμη πιο εύκολα τι γίνεται.

[/troll]

[Kercyn]

link please?

 

Δε θυμάμαι ρε γαμώτο, κάτι τέτοια ωραία τα χάνω.

[GReaperEx]

Πες του ότι έτσι γλυτώνουμε το nesting level του if οπότε ο "tester" θα καταλάβει ακόμη πιο εύκολα τι γίνεται.

 

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

// Θεωρώ το δεύτερο τρόπο καλύτερο



int foo(int bar)

{

    if (bar == 10) {

        return 1;

    } else {

        return 0;

    }

}



int foo(int bar)

{

    return bar == 10;

}

[the other one]

Γενικά θεωρείται καλή τακτική να αποφεύγεις όσο γίνεται τα break/continue ίσως πάνω σε αυτή τη λογική το είπε. Βέβαια αυτό αφορά κυρίως πολύπλοκο κώδικα σε ένα τόσο απλό for λίγο έχει σημασία.

[Zaytsev]

Κάποιοι έχουν μπερδέψει την έννοια του "tester" με την έννοια του code reviewer.

Χώρια που tester δεν υπάρχει, η ειδικότητα είναι Q&A.

[imitheos]

Κάποιοι έχουν μπερδέψει την έννοια του "tester" με την έννοια του code reviewer.

Χώρια που tester δεν υπάρχει, η ειδικότητα είναι Q&A.

Για αυτό το έβαλα σε εισαγωγικά. Δες και το μήνυμα του defacer που το έθιξε επίσης.

 

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

 

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

 

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

[defacer]

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

 

Όχι, αλλά Αγγλία που ήταν και η μόνη άμεση επαφή μου εκτός Ελλάδας το sample size ήταν πολύ μικρό. Πάλι βέβαια δεν είδα κανέναν να ξέρει.

 

Γενικά θεωρείται καλή τακτική να αποφεύγεις όσο γίνεται τα break/continue ίσως πάνω σε αυτή τη λογική το είπε. Βέβαια αυτό αφορά κυρίως πολύπλοκο κώδικα σε ένα τόσο απλό for λίγο έχει σημασία.

 

Τέτοια blanket statements χωρίς αιτιολόγηση είναι σούπερ ύποπτα. Γιατί θεωρείται καλή τακτική;

 

Νομίζω πως έχω ξαναγράψει σε κάποιο παρόμοιο θέμα για ποιούς λόγους πιστεύω ότι αυτό

for(...) {
    if(i == x) {
        // do something
    }
}

είναι χειρότερο από αυτό

for(...) {
    if(i != x) {
        continue;
    }
    // do something
}

εκτός κι αν το do something είναι μία-δυο γραμμές και το loop δεν έχει τίποτα άλλο μέσα.

[g8anos]

Κάποιοι έχουν μπερδέψει την έννοια του "tester" με την έννοια του code reviewer.

Χώρια που tester δεν υπάρχει, η ειδικότητα είναι Q&A.

 

Δουλεύω σαν "Tester", είναι ο σύντομος ορισμός όταν μιλάμε μεταξύ μας οι πληροφορικάριοι στις εταιρείες. (Εννοείται οτι δεν ειναι ο επίσημος ορισμός). Ο επίσημος τίτλος ήταν "Software verification engineer". Τώρα είμαι "Software verification manager", αλλά ουσιαστικά πάλι ο "Tester" είμαι για τους συνάδελφους. (και εγώ λέω τον "architect" απλά "Developer")

 

Επίσης να διορθώσω και αυτό που διάβασα μερικά posts πιο πάνω, μια χαρά βλέπει ο "Tester" τον κώδικα, εάν κάνει white-box testing στο project που του έχει ανατεθεί. Κώδικα ΔΕΝ βλέπει εάν κάνει black-box testing.  

[defacer]

Επίσης να διορθώσω και αυτό που διάβασα μερικά posts πιο πάνω, μια χαρά βλέπει ο "Tester" τον κώδικα, εάν κάνει white-box testing στο project που του έχει ανατεθεί. Κώδικα ΔΕΝ βλέπει εάν κάνει black-box testing.

Έχεις βέβαια δίκιο, απλά ο περισσότερος κόσμος (υποψιάζομαι συμπεριλαμβανομένου του καθηγητή) δεν έχει δει ποτέ formal white box testing στη ζωή του. Όπως και να 'χει, το black box είναι μακράν πιο συνηθισμένο.

[Zaytsev]

Δουλεύω σαν "Tester", είναι ο σύντομος ορισμός όταν μιλάμε μεταξύ μας οι πληροφορικάριοι στις εταιρείες. (Εννοείται οτι δεν ειναι ο επίσημος ορισμός). Ο επίσημος τίτλος ήταν "Software verification engineer". Τώρα είμαι "Software verification manager", αλλά ουσιαστικά πάλι ο "Tester" είμαι για τους συνάδελφους. (και εγώ λέω τον "architect" απλά "Developer")

Σύμφωνα με τα επίσημα standards της IEEE, αυτό που αναφέρεις ως "Software Verification Engineer", είναι o "code reviewer" που είπα παραπάνω. Ο Q&A δε βλέπει κώδικα, είναι ο "πελάτης/χρήστης" της εφαρμογής που τη δουλεύει και αναφέρει προβλήματα.

 

Τίτλους μπορεί να δίνει ο καθένας κατά βούληση. Για αυτό υπάρχουν θεσμοθετημένα standards για να μιλάμε την ίδια γλώσσα. Τώρα, πολλές εταιρίες, για χάρη κόστους, μπορεί να μπλέκουν ρόλους, όπως πολύ συχνά engineers κάνουν code reviews στον κώδικα της υπόλοιπης ομάδας, ή έχω δει product owners να κάνουν Q&A, και πολλά άλλα παράδοξα.