neverlastn

Πράγματι το Novice to Ninja είναι το καλύτερο εισαγωγικό. Σήμερα αγόρασα και το Early Access βιβλίο "Secrets of the JavaScript Ninja" http://jsninja.com/. Είναι από αυτόν που έχει γράψει το jQuery! Έχει γράψει επίσης το "Pro JavaScript Techniques". Μην ψαρώνετε από τα Ninja και Pro... είναι καλύτερο να μην καταλαβαίνεις το 60% του βιβλίου παρά να είσαι στο σκοτάδι και να χαραμίζεις τον χρόνο σου γιατί δεν ξέρεις τα 2-3 tricks που έχουν αυτά τα βιβλία μέσα και μπορείς να χρησιμοποιήσεις άμεσα. Για παράδειγμα δες εδώ - τα tricks είναι απλά και άμεσα εφαρμόσιμα από beginners αλλά σίγουρα δεν τα λέει ένα beginners βιβλίο μέσα.

Ωραίο post Την Py θα την βρεις πανέμορφη αν έρχεσαι από Java/php και γενικότερα έχεις OO εμπειρία. Όταν έρχεσαι από Fortran.. παίρνει αρκετό χρόνο γιατί πρέπει να μάθεις OO, ένα λίγο πιο functional τρόπο προγραμματισμού... γενικά είναι μεγάλη η απόσταση. Από πλευράς performance θα έχεις σημαντικό penalty σε σχέση με τη C/Fortran σε αυτές τις εφαρμογές.

Για όποιον ψάχνεται να ξεκινήσει με Flash, μπορεί να ρίξει μία ματιά σε αυτό το Flash Tutorial Video στα Ελληνικά: http://saites.gr/web-development/pos-mporo-na-kano-paixnidia-kai-quiz-me-to-flash

Για όσους ένοιωσαν κάτι γαργαλιστικό και μία γερή δόση αλήθειας σε αυτά που έλεγα σε προηγούμενες απαντήσεις περί O() κ.τ.λ. βρήκα ένα καταπληκτικό βιβλίο που μιλάει μεταξύ των άλλων και για το ποιό είναι το πιο γρήγορο sort το 2009+ (κεφάλαιο 8). "The Art of Concurrency" λοιπόν... http://shop.oreilly.com/product/9780596521547.do Επίσης ρίξτε μία ματιά στην ανάλυση του τυπά στο τέλος σε αυτό το post: http://www.mysqlperformanceblog.com/2007/08/18/how-fast-can-you-sort-data-with-mysql/ Όπως θα δείτε, ακόμα και π.χ. στη MySQL merge-sort με σωστά μεγέθη buffers είναι πιό γρήγορο από pure quicksort. Cheers!

Το μόνο κακό όταν δούλευα σε embedded ήταν ότι φαινόταν πιό cool απ'ότι ήταν από μακρυά. Στο τέλος απλά ξόδευες απίστευτο χρόνο λόγο των περιορισμένων δυνατοτήτων debugging και του σχετικά περιορισμένου documentation (στα embedded μήν ξεχάσετε να διαβάσετε και να καταλάβετε το errata - θα σας σώσει χρόνο) Anyway. Αυτό που σκέφτηκα ότι θα βοηθήσει μιας και υπάρχει όλο αυτό το ενδιαφέρον στο thread, είναι να κάνω ΔΩΡΕΑΝ ένα insomnia exclusive εισαγωγικό webinar (45 λεπτά) στην python, scrappy, mongodb και cloud computing (AWS). Αν σας ενδιαφέρει να παρακολουθήσετε (θα μπορούσαμε να το κάνουμε τη Κυριακή) please συμπληρώστε το παρακάτω survey για να ξέρω τι σας ενδιαφέρει... http://www.surveymonkey.com/s/5QKCWD3 Αν δεν ενδιαφέρει αρκετούς (π.χ. λιγότερες από 15 συμμετοχές) το webinar δε θα γίνει (sorry)! Υ.Γ. Αν το webinar γίνει θα το γράψουμε σε video ώστε να μπορείτε να το δείτε και μετά αλλά ο μόνος τρόπος να ρωτήσετε ότι δεν καταλαβαίνετε είναι να είστε εκεί live. Υ.Γ.2 Ο εξοπλισμός που χρειάζεται για τη συμμετοχή είναι browsser με Java (και προαιρετικά μικρόφωνο) Υ.Γ.3 Δεν είμαι expert στην Python, ούτε δάσκαλος ούτε τίποτα certified. Παρόλα αυτά πιστεύω ότι θα είναι ενδιαφέρον, χρήσιμο και fun!

Gumstix, Mini-ITX = Embedded = καλύτερα απόφυγέ το Android,iOS,Windows Mobile = Mobile = Αυτή η αγορά ανοίγει πολύ και είναι πολύ πιό εύκολη από την Embedded Τώρα όταν στο Mini-ITX έτρεχα SuSE εγώ το έλεγα... μάλλον desktop

Ναι, αλλά δεν έχεις το χρόνο να το κάνεις αυτό manually, ειδικά όσο αυξάνονται οι χιλιάδες γραμμές κώδικα που διαχειρίζεσαι γιατί η πολυπλοκότητα του προβλήματος αυξάνει εκθετικά. Ναι. 10 και 35 λεπτά είναι το ίδιο. Πάρα πάρα πάρα πολλά για κάθε πρακτική χρήση!! Κι εγώ μαζί σου είμαι... τις πρακτικές που λές τις κυνηγάω δια ροπάλου - μόνο που αυτή τη φορά η κακή πρακτική είναι αυτή που προτείνεις. Κάθεσαι και προσπαθείς να μάθεις στα παιδάκια πώς να σώζουν 10 κύκλους ρολογιού σε ένα CPU που έχει "καρφωθεί" στα 2.2GHz και δεν τους μαθαίνεις πώς να γράφουν για την πραγματικότητα, τα 4,8 και 16 cores και τα web services. Ακαδημαϊκά καλά κάνεις. Πρακτικά αυτή η νοοτροπία μπορεί να καταστρέψει μία γενιά Ελλήνων προγραμματιστών που μέσα από το σχολείο και τις συμβουλές σου θα τρώει βδομάδες να κάνει τα 35 λεπτά 10 (και να γράψει ένα paper) ενώ ο Αμερικάνος θα κάνει το ίδιο πράγμα σε 2 δευτερόλεπτα. Επίσης για άλλη μία φορά disclaimer ΜΕΓΑΛΟ για όποιον πάει να πειράξει οτιδήποτε performance orriented: Καταλάβετε τον Amdahl's law Αν είσαι Ινδός και γράφεις σκατά κώδικα, μετά το πρώτο draft θα κάνεις profiling και θα δείς: >Function A 70% Function B 20% Function C 5% Rest ... Σε αυτή τη περίπτωση είσαι μία χαρά!! Μπορείς να κάνεις αυτό που λέει ο migf1. Πέσε με τα μούτρα στην Function A και κάν'την 100 φορές πιό γρήγορη. Αν όμως είσαι Έλληνας ή Ρώσος και εξ'ορισμού γράφεις "σφιχτό" κώδικα... τότε μετά το profiling θα δείς: >Function A 17% Function B 14% Function C 9% Rest ... Σε αυτή τη περίπτωση αυτό που λέει ο migf1 δεν θα σου δώσει τίποτα και γενικότερα είναι ελάχιστα που μπορείς να κάνεις για να βελτιώσεις το performance αυτού του προγράμματος. Ο λόγος είναι... Amdahl's law!! Αν βελτιώσεις 100000% την συνάρτηση A με πολύ κόπο μόχθο και υδρώτα ξοδεύοντας βδομάδες το μόνο που θα πετύχεις είναι 17% βελτίωση στο πρόγραμμά σου... και μόλις το κάνεις αυτό και περάσεις στη Β πας για άλλο 14%. Αυτό ούτε Bonus θα σου δώσει ούτε το βραβείο Nobel. Μάλλον θα σου δώσει όμως ένα [κουτί] για να μαζέψεις τα πράγματα και να πας σε άλλη εταιρεία/εργαστήριο, whatever! Το μόνο λοιπόν που μπορείς να κάνεις στη περίπτωση β) που λέω παραπάνω είναι είτε κάποιο πολύ δυνατό στρατηγικό refactoring all-over the place είτε να δεις πώς μπορείς να παραλληλήσεις τον αλγόριθμο για να εκμεταλλεύεται όλα τα CPUs είτε να κάνεις "outsource" τον αλγόριθμο σε κάποιο web-service έτσι ώστε να εκμεταλεύεσαι το γεγονός ότι πολλοί χρήστες μπορεί να τον έχουν εφραμόσει στο ίδιο dataset και συνεπώς μπορεί να είναι σε κάποια cache. Ναι/όχι! Embedded programming είναι πάρα πολύ μικρή αγορά. Mobile programming ναι - αλλά και πάλι αυτή τη στιγμή τα κινητά είναι σχετικά thin clients και πάντα χτυπάνε κάποιο server. Παρόλα αυτά λόγω ζωής μπαταρίας και ότι η κατανάλωση πάει με το τετράγωνο της τάσης δεν μπορούν να ανεβάσουν τη συχνότητα και εκεί - το μόνο που μπορούν να κάνουν είναι να πάνε σε πολλαπλούς επεξεργαστές (για άλλη μιά φορά). Επίσης εκεί το data locality είναι ακόμα πιό σημαντικό μιας και οι caches είναι ακόμα μικρότερες και οι δίαυλοι λιγότερο αποδοτικοί. Υ.Γ. Data locality = Αν ένας αλγόριθμος χτυπάει σε ένα array με τη σειρά τα a[0], a[1], a[51], a[1045], a[3], a[12], a[15004] = ΠΟΛΥ ΚΑΚΟ, αν ένας αλγόριθμος χτυπάει a[0], a[1], a[1], a[2], a[3], a[4] ... a[1000], a[1001], a[1000], a[1001] = ΠΑΡΑ ΠΟΛΥ ΚΑΛΟ! (Ακόμα κι αν η πολ/τα του 2ου αλγορίθμου είναι χειρότερη θα έχει πολύ λιγότερα cache line misses και μπορεί να είναι σημαντικά πιό γρήγορος). Και πάλι ο profiler έχει την τελευταία λέξη. OK guys, για να το αμβλύνω λιγάκι γιατί καταντάει βαρετό. Ναι, υπάρχει η πολυπλοκότητα και ναι μετράει, και ναί, το quicksort είναι κατά μέσο όρο πιό γρήγορο και ναί, αν τα δεδομένα σου έχουν συγκεκριμένα στατιστικά χαρακτηριστικά μπορείς να το εκμεταλευτείς για να επιλέξεις τον κατάλληλο αλγόριθμο που θα είναι ο πιό γρήγορος. Παρόλα αυτά, σε αυτά τα προβλήματα θα συνιστούσα να μπείτε αφότου έχετε βάλει όλες τις caches σας ώστε να μην κάνετε διπλό δουλειά, αφότου έχετε εξετάσει αν είναι trivialy παραλληλισμο, αφότου έχετε δει από τον Amdhal's law ότι μπορείτε να το βελτιώσετε σημαντικά και αφότου έχετε επιβεβαιώσει με τους managers/supervisors σας ότι το να γίνει X% πιό γρήγορο κάνει justify τον μισθό σας για τον χρόνο που θα σας πάρει. Οι ακαδημαϊκοι σας ετοιμάζουν για να γράφετε λειτουργικά συστήματα και άλλα ενδιαφέροντα και sexy πράγματα. Δυστυχώς όμως η πραγματικότητα είναι ότι οι περισσότεροι από εσάς αυτό που θα γράφετε είναι application code και η λύση στο ότι κάτι είναι αργό συνήθως θα είναι "ok-θα αγοράσουμε την enterprise licence" ή "ok-κάνε upgrade στην καινούρια έκδοση της βιβλιοθήκης που είναι 1.8x πιό γρήγορη". Σε κάποιες περιπτώσεις η λύση στο ότι το πρόγραμμα είναι αργό θα είναι "μην ανησυχείς - θα τους δώσουμε 2 μήνες iTunes δωρεάν συνδρομή - θα το αγοράσουν ούτως ή άλλως". Τώρα για python, java, C/C++ όλες οι γλώσσες ειναι χρήσιμες και είναι καλό να ξέρεις πολλές ώστε να χρησιμοποιείς τη πιό κατάλληλη κάθε στιγμή. Κατά κανόνα κάθε νεότερη γλώσσα είναι ΠΙΟ ΕΥΚΟΛΗ από τις προηγούμενες αλλιώς δεν θα γινόταν αποδεχτή. Παρόλα αυτά γύρω από κάθε νεότερη γλώσσα υπάρχει ο ΦΟΒΟΣ του αγνώστου. Προσπαθείστε να ξεπεράσετε αυτόν τον φόβο. Η Python είναι πιό εύκολη από τη C++ και η C++ πιό εύκολη από assembly (χμμ... ίσως ) Δοκιμάστε καινούρια πράγματα! Φιλιά πολλά, neverlastn

Κι αυτό είναι πολύ καλό και το'χει γράψει ένας Έλληνας: "Learn Python in Ten Minutes" by Stavros Korokithakis http://leanpub.com/learn-python Το tutorial είναι και δωρεάν στο blog του: http://www.korokithakis.net/tutorials/python/ Το κουμπάκι "Εισαγωγή media" - τελευταίο στην λίστα http://www.youtube.com/watch?v=k6U-i4gXkLM

Συμφωνώ απόλυτα!! Μπααα... ούτε στο παρελθόν αλλά ούτε και στο όλο πιό παράλληλο παρόν... απλά κάνεις exhaust τη μνήμη γενικά μιλόντας. Σε γενικές γραμμές θέλεις να κάνεις optimize το σύστημα (και όχι τις βαθμίδες) για maximum throughput/minimum latency (εξαρτάται από τις πρωτεραιότητες). Optimal υποτμήματα εξασφαλίζουν βέλτιστο σύστημα αλλά ουσιαστικά το ίδιο αποτέλεσμα θα είχες αν έκανες optimize ΜΟΝΟ τα τμήματα που βρίσκονται στο "critical path". Για όλα τα υπόλοιπα απλά χαραμίζεις τουλάχιστον τον χρόνο σου (και κινδυνεύεις όπως είπα να ξεμείνεις από buffers/μνήμη). (Amdahl's law + theory of constraints) Βρε migf1... το πρόβλημα είναι ότι ξέρω τι λες... και αυτό που λες έχει περάσει εδώ και τουλάχιστον 6-7 χρόνια - sorry. Είναι απόλυτα ίδια η πολ/α των δύο αλγορίθμων και όπως είπα στο προηγούμενο post Ο(bublesort)=O(quicksort)=σκατά! Δεν κάνουμε sort 1kb πλέον, νομίζω ότι το ξέρεις, έτσι δεν είναι; Επίσης νομίζω ότι το ξέρεις ότι πλέον έχεις 4 επεξεργαστές + ένα cluster στο Amazon και πρέπει να κάνεις sort συνήθως GB's έτσι δεν είναι; Τα παιδιά που δεν έχουν ασχοληθεί και διαβάζουν αυτό το post τώρα πρέπει να ξέρουν τι παίζει σήμερα και όχι στο 2001. Ας το εξηγήσω μία στιγμή... Όταν έχεις να κάνεις sort 100Gb, είτε quicksort χρησιμοποιήσεις είτε bubblesort... θα πάρει αιώνες. Κοινώς μη αποδεχτό χρόνο. Καλώς; Ο λόγος δεν είναι το CPU δηλαδή και 1THz CPU να είχες και πάλι θα έπαιρνε αιώνες λόγω πολυπλοκότητας+μέγεθους dataset. Τα O(whatever) είναι άχρηστα σε μεγάλο βαθμό γιατί μιλάνε για τους πόσες επαναλήψεις θα πάρει στο CPU ενώ εμείς το ρεαλιστικό metric που θέλουμε είναι πόσο localy δουλεύει στα δεδομένα γιατί το αργό δεν είναι να επεξεργαστείς τα δεδομένα, αλλά να τα φέρεις είτε από το net, είτε από τον δίσκο. Το μόνο λοιπόν που μπορείς να κάνεις είναι mergesort. Στο "sort" χρησιμοποίησε ότι θέλεις - bubblesort, quicksort... οτιδήποτε έχει το μικρότερο O ... δεν είναι και πολύ σημαντικό. Το σημαντικό είναι να κάνεις ένα efficient "merge" το οποίο στην περίπτωση του προβλήματος της ταξινόμησης είναι ψιλό-trivial όπως και σε πολλά άλλα προβλήματα αλλά όχι πάντα. External sorting λοιπόν και mergesort πρέπει να καταλάβει κανείς αν θέλει να είναι στη σωστή κατεύθυνση για να κάνει efficient υπολογισμούς το 2011. Αυτό πιό γενικά ονομάζεται Map-Reduce. Εκεί λοιπόν παίζει η ταχύτητα του αλγορίθμου σου σήμερα και όχι στα O's. Νομίζεις ότι θα μπορούσες να συμφωνήσεις σε αυτό ή όχι; Ναι είμαι πάρα πολύ σίγουρος, βασικά είναι πρόβλημα της γλώσσας (συνδυασμός έλειψης destructors + ότι μπορείς να έχεις κατευθείαν πρόσβαση στη μνήμη). Αν δεν έχεις destructors που καλούνται αυτόματα στο τέλος του scope δεν μπορεί να γίνει αυτόματη απελευθέρωση μνήμης και πρέπει να βάλεις τις δικές σου συναρτησούλες για να πεις - ξέρεις μεταβλητούλα δε σε χρειάζομαι άλλο - το οποίο είναι πολύ κακό α) γιατί οι άνθρωποι πάντα θα το ξεχνάνε (memory leaks) και β) γιατί οι άνθρωποι θα το βάζουν ενώ υπάρχουν ακόμα references στην μεταβλητή (seg. faults). Αυτό το πρόβλημα δε λύνεται στην C αλλά στην C++ και under conditions (νομίζω ότι υπήρχε ένας πολύ κάφρικος, ugly και system specific way να λυθεί και στη C αλλά δε θυμάμαι πλέον). Κατάλαβα που έγινε η "παρεξήγηση". Όταν έλεγα να "μαζεύεις τα σκουπίδια σου" δεν εννοούσα συγκεκριμένα garbage collection αλλά αυτοματοποιημένο memory management γενικότερα. Αυτό εξαρτάται σε μεγάλο βαθμό από την αρχιτεκτονική. Στη λεγόμενη Harvard architecture (χρησιμοποιείτε κυρίως σε DSP's) μπορεί να υπάρχουν δύο L1 caches η Data και η Instruction. Στα περισσότερα general purpose συστήματα οι δύο cache's είναι μία που παρέχει τόσο Instructions όσο και Data. Σε γενικές γραμμές η L1 είναι μικρή (μερικά kb) και είναι κοντά στον επεξεργαστή (πάνω στο ίδιο chip).

Cool, σε C και assembly ΠΡΕΠΕΙ να είναι μία γραμμένη μία τέτοια βιβλιοθήκη Αυτό είναι ΠΟΛΥ ΠΟΛΥ ΠΟΛΥ σωστό. Παιδιά να σας πω ένα μυστικό... ΔΕΝ ΕΧΕΤΕ ΙΔΕΑ τι είναι πιο γρήγορο... Μα το θεό - ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ! Και μη το πάρετε προσωπικά... Μπορώ να σας υπογράψω ότι ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ! Ο λόγος είναι ότι τα πράγματα αλλάζουν σχεδόν κάθε 2 χρόνια ή πιό σύντομα. Οι *** που διδάσκουν στο πανεπιστήμιο (πολυπλοκότητες κ.τ.λ.) είναι για παιδιά - τελείως θεωρητικές. Για να μπορείς να βγάλεις συμπεράσματα με βάση αυτές και να εκτιμήσεις σωστά θα πρέπει να ξέρεις αρκετά καλά το hardware σου και τα όριά του. QuickSort και BubbleSort εχουν ΤΗΝ ΙΔΙΑ πολυπλοκότητα = σκατά Η μόνη sort που είναι πιό efficient από αυτές (και η μόνη ουσιαστικά βιώσημη σήμερα) είναι η MergeSort (!!) Α... και αν θέλετε ακόμα πιό γρηγόρα B+ δέντρα... δυστυχώς. --- Ελπίζω να σας κέντρισα το ενδιαφέρον και να σας τσάντισα αρκετά ώστε να διαβάσετε και λίγο παρακάτω... Όπως λοιπόν ξέρετε το CPU είναι γρήγορο... και άχρηστο χωρίς δεδομένα. Έχουμε λοιπόν L1 Cache, L2 Cache, RAM και τέλος τον Δίσκο... Αν θέλεις να είσαι γρήγορος - ο στόχος σου είναι να μη χτυπήσεις ποτέ τον δίσκο - και αν είναι δυνατόν να μένεις όσο το δυνατόν περισσότερο στην L1 Αυτό σημαίνει ότι αν π.χ. μπορείς να χωρέσεις δύο arrays των 256k στην L1 και να κάνεις vector sort και να βγάλεις min/max/μέσο όρο, τέλεια! Αυτό πρέπει να κάνεις... σε 265k. Αν έχεις 100 Gb δεδομένα αυτό που πρέπει να κάνεις για να είσαι γρήγορος είναι το εξής: >foreach 256k chunk of 100Gb { prefetch hint for the next 256k sort(256k) <- min(256k) <- max(256k) <- sum(256k) <- Αυτά τα 4 μέσα σε ένα "for" παράλληλα } Aggregate results (if necessary) i.e. merge από τη mergesort μόνο για το sort και μία διαίρεση του sum με το count για να βρούμε το μέσο. Αυτός είναι ο πιό γρήγορος τρόπος να κάνουμε sort σήμερα (και ουσιαστικά τζάμπα να υπολογίσουμε και μερικά min/max/average). Ακόμα κι έτσι τον περισσότερο χρόνο θα καθόμαστε να περιμένουμε από τον δίσκο η την RAM να φέρει τα δεδομένα. Γι'αυτό καλύτερα να έχουμε να τρέχουν 50 τέτοιες διεργασίες παράλληλα (όχι ότι θα μας σώσει... αλλά καλύτερα). Αυτό πάνω κάτω γίνεται και σε πολύ μεγαλύτερα datasets με το mapreduce (δειτε hadoop - μπορείτε να παίξετε μαζί του σχεδόν τζάμπα με Amazon Web Services). Αυτή είναι η πολυπλοκότητα σήμερα... πώς να εκμεταλευτείς τους 4 πυρήνες και το κάθε CPU να χρειάζεται να δει τα δεδομένα σου Μόνο μία φορά. Αυτά που μαθαίναμε στο πανεπιστήμιο είναι πρακτικά άχρηστα αλλά είναι πολύ καλό που τα μάθαμε γιατί μας έκαναν να ξέρουμε το πρόβλημα... και να αναζητούμε συνεχώς την καλύτερη λύση (η οποία σήμερα είναι η παραπάνω). Τώρα αν έχετε ένα κομμάτι κώδικα και θέλετε να το κάνετε γρήγορο... Αφήστε την C/C++ και τις γλώσσες και πιάστε το Valgrind και δείτε που είναι το πρόβλημα. Το πιθανότερο είναι ότι ΔΕΝ είναι εκεί που φαντάζεστε. Δείτε και καταλάβετε καλά τον Amdahl's law http://en.wikipedia.org/wiki/Amdahl%27s_law . Ακόμα κι αν επιταγχύνεις τον κώδικά σου 100000 φορές μπορεί να έχεις συνολικά μόνο 1% επιτάχυνση του προγράμματός σου. Αυτός ο νόμος εξηγεί το γιατί. Δείτε επίσης το parallel computation thesis. http://en.wikipedia.org/wiki/Parallel_computation_thesis Αυτό λέει ότι ο βαθμός στον οποίο μπορεί κάτι να γίνει παράλληλο είναι σε αναλογία (χοντρικά) με τη μνήμη που χρειάζεται το πρόγραμμα. Γι'αυτό τον λόγο αν στο μέλλον θέλεις να γράφεις πολύ γρήγορα κώδικα καλά θα κάνεις να μάθεις και να καταλάβεις functional γλώσσες προγραμματισμού π.χ. Erlang γιατί οι functional γλώσσες έχουν παραδοσιακά ελάχιστο state = είναι σχεδόν trivial να τις παραλληλήσεις (όχι πάντα). Αυτά για την ταχύτητα. Ελπιζω να συμφωνείτε πλέον μαζί μου ότι ΔΕΝ ΞΕΡΕΤΕ ΤΟΝ ΧΡΙΣΤΟ ΣΑΣ! Ούτε εγώ ξέρω! Όταν έχω ένα κομμάτι κώδικα και ΑΝ (όπως είπε και ο φίλος - που είναι πολύ σωστός - PanosJee παραπάνω, σπάνια) το πρόβλημα είναι ότι είναι αργός τότε πρέπει να ανοίξεις τον profiler, να δεις τι φταίει, να δεις αν αξίζει να κάνεις κάτι (Amdahl's law) και μόνο τότε να δώσεις κάποιον χρόνο να το βελτιώσεις. Τέλος καταλάβετε ότι η Python ή κάθε High Level Language είναι πολύ πιό γρήγορη (performance & productivity) ... για μεγάλα datasets και κάτω από time/budget constraints (=στην πραγματικότητα), ΓΙΑΤΙ σε αφήνουν να εστιάσεις στα πραγματικά προβλήματα (που είπαμε παραπάνω - πώς να παραλληλήσεις) από τον να κυνηγάς pointers και memory leaks. Επίσης να ξέρετε ότι στη C/C++ όταν γράφεις π.χ. >taks(void*a) { myclass * b = (myclass *)a; b->whatever(); (double*)(a+2512) = 433.6; } ... και όλη αυτή τη βρωμιά των casts κ.τ.λ. ο compiler σου τα παίζει και δεν μπορεί να κάνει τίποτα optimize. Ουσιαστικά αν έγραφες Java και επειδή στις λίγο πιό πολιτισμένες από την C γλώσσες δεν παίζεις με τη μνήμη κατευθείαν, ο compiler μπορεί να κάνει αρκετά καλύτερο optimization. Π.χ. μπορεί να δει μία HLL ότι από την κλάση σου δε χρησιμοποιείς 6 πεδία = 24bytes λιγότερα κάθε κλάση = στα 100M αντικείμενα 2Gb λιγότερο bandwidth/πέρασμα = μπορεί (πολύ ακραία) και 2-πλάσια ταχύτητα; Στην C δεν θα μπορούσε να δει ότι δεν χρησιμοποιείς 6 πεδία γιατί μπορεί να έχεις κάποιον ηλίθιο pointer που τα χρησιμοποιεί με κάποιον βρώμικο τρόπο. Αυτό δεν μ'αρέσει: Από αυτό... >int main( void ) { string str ("Test string"); cout << "The size of str is " << str.size() << " bytes.\n"; cout << "The length of str is " << str.length() << " bytes.\n"; return 0; } σε αυτό... >int main( void ) { String *s = str_new("Test string"); printf("The size of str is %lld bytes\n", s->size ); printf("The length of str is %lld bytes\n", s->length ); str_delete( s ); return 0; } Η διαφορά είναι μεταξύ σε κάποιον που μπαίνει μέσα (α) και σε κάποιον που έχει 9 δάνεια και ετοιμάζεται να πάει φυλακή (β). Καμία σχέση πάντως με: >>>> s="Test String" >>> "The size of str is %d bytes\n" % len(s) (που μπορεί να βγάλει και κάποια χρήματα) Το να πρέπει να μαζεύεις τα σκουπίδια σου είναι απίστευτο overhead σε μεγάλα projects και η C++ με πολύ υδρώτα και smart pointers το ψιλό-λύνει. Η C δεν μπορεί να το κάνει αυτό - τελεία και παύλα. Πέστα χρυσόστομε Ακριβώς και γι'αυτό συνήθως τα βάζουμε ώς service ώστε να μη χρειάζεται να κάνουν ούτε startup! Μεγάλη αλήθεια. Μπορεί να έχεις ανθρώπους που μπορούν να κάνουν τρελά πράγματα αλλά δεν ξέρουν τίποτα με την python. Πάντως για εμένα είναι πάρα πολύ μεγάλη επιτυχία το συγκεκριμένο thread - γιατί το να βάζεις δίπλα δίπλα και να συγκρίνεις C/C++ με python στην Ελλάδα και να μην έχεις φάει τρελό χαστούκι είναι ένα μεγάλο επίτευγμα. Για εμένα σημαίνει ότι πάμε πολύ καλά και τουλάχιστον μερικές 10-αδες άτομα θα αποφασίσουν να δοκιμάσουν την python και άλλες τρελές γλώσσες και θα μπορούν να επιλέξουν με βάση τη γνώση και όχι την άγνοια και τον φόβο. P.S. Αν γράφετε παιχνίδια ή ρομποτικά ή high frequency trading κ.τ.λ. μάθετε C/C++.

Μα η python παίρνει max μια μέρα - try this at home! Από το... στο εγώ προτιμώ το πρώτο! Μπλιάχ... δε βλέπεται! (Sorry αν την έγραψες εσύ - just kidding). Χρειάζομαι ειδικά γυαλιά για να g_διαβάσω g_αυτόν g_τον(g_κώδικα). Το πρόβλημα είναι αυτό. Χαχαχα... σιγά μη καθόταν να το διαβάσει. Θα έκανε stack overflow μετά από 2 δευτερόλεπτα. Πολύ σωστό. Όχι ρε συ... τουναντίον! Μακάρι η Ελληνική αγορά να ήταν σε τέτοιο επίπεδο. Ζήτημα αν 5 εταιρίες στην Ελλάδα χρησιμοποιούν AWS (και το ξέρουν) ή αν υπάρχουν 100 developers που κάνουν node και έχουν χρησιμοποιήσει redis. Για την Ελληνική αγορά Visual Basic και php και ASP είναι μιά χαρα. MS SQL Server, Access, λίγη Java... άντε κι ένα memcached για να το κάψουμε!! Η εκπαίδευση είναι σε καταπληκτικό επίπεδο σε σχέση με εξωτερικό - σίγουρα. Τα ΤΕΙ είναι ΑΕΙ του εξωτερικού και τα ΑΕΙ είναι Master+ από επίπεδο προγράμματος σπουδών. Το μόνο πρόβλημα είναι ότι δεν ξεχωρίζουν πλέον τι είναι σημαντικό και τι όχι. Τα περισσότερα προγράμματα είναι υπερφορτωμένα λόγω του φόβου της *** μπουυυυυ *** αγοράς. Ας μάθουμε στα παιδιά τα πάντα - όλο και κάτι θα πιάσουν... Το κακό είναι ότι τώρα λοιπόν που τα προγράμματα σπουδούν έχουν 3x τα μαθήματα που θα έπρεπε να έχουν, ούτε οι καθηγητές ούτε οι φοιτητές έχουν τον χρόνο να κάτσουν να εμβαθύνουν σε ένα - οπότε γίνεται ένα γενικό πασάλειμα. Οι καλοί θα τα πιάσουν αλλά οι μέσοι θα χρειαστεί να αντιγράψουν Και that's all όλοι φαίνονται ωραίοι... οι καθηγητές, οι φοιτητές και τα προγράμματα... αλλά όταν έρχεται η ώρα να σφίξουν τα ζωνάρια... ουπς!! Από που μας ήρθε αυτό; Πάντως το επίπεδο είναι πολύ ψηλο.

Αβέρτα open source - no problem... Αλλά πιστεύω ότι αν ψάξεις τα trends μάλλον και από open source όλο και λιγότερα projects τρέχουν σε C. Ουσιαστικά για να είμαστε ειλικρινείς Ο ΜΟΝΟΣ ισχυρός λόγος για να χρησιμοποιήσεις C σήμερα δεν είναι ούτε καν performance αλλά μόνο αν η εφαρμογή σου έχει Hard Real Time Constraints π.χ. drivers χαμηλού επιπέδου, network πράγματα, οτιδήποτε ρομποτικό, high-frequency trading κ.τ.λ. Η αχίλλειος πτέρνα κάθε τι πάνω από την C/C++ λέγεται Garbage collector

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

Ω ναί... δεν αμφιβάλω... μπορείς να αλλάξεις και την stdlib αν θέλεις και με λίγο hack στον gcc να βάλεις 4/8 bytes padding στην αρχή κάθε const char *. Αλλά γιατί να αφιερώσω αυτά τα 20 λεπτά να φτιάξω τη δομή που λες; Παρεπιπτόντως με το που αρχίζεις τις δομές string αν δεν θέλεις να γίνει πολύ ugly ο κώδικας καλύτερα να πας κατευθείαν σε C++ και std::string. Πολύ sick - respect!! Κοίτα, όλα είναι γραμμένα σε C. Η Java είναι γραμμένη σε C, το linux & τα Windows είναι γραμμένα σε C. Και η ίδια η C είναι γραμμένη σε C κι assembly. Δε βλέπω όμως να επιχειρηματολογεί κανείς για το ότι θα πρέπει να γράφουμε σε assembly. Νομίζω ότι είμαι εντάξει... γλώσσες συγκρίνουμε Πολύ αμφιβάλω... αλλά δεν νομίζω ότι οι τύποι που κάνουν drivers για DVD-R's είναι και πάρα πολλοί σ'αυτόν τον κόσμο. Δεν υπάρχουν και τόσα πολλά με περιορισμένους πόρους πλέον. Το "time to market" κάνει drive τα πάντα (δυστυχώς για εμάς τους καλιτέχνες). Συμφωνώ. Κι εγώ ο ίδιος αν μου ερχόταν χοροπηδηχτός ένας ruby-ας πάνω κάτω αυτά που λες εσύ θα του έλεγα, αλλά θα εστίαζα λίγο περισσότερο στο ότι η C είναι standard έχει τεράστοιο community και σου δίνει τον απόλυτο έλεγχο που σημαίνει απίστευτα μικρό memory fingerprint. Το μόνο πρόβλημα είναι ότι στο περιβάλλον που βρισκόμαστε στην Ελλάδα... με όλα τα πανεπιστήμια να πορώνουν τους πάντες να μάθουν C ώστε να μη χρειάζεται να μάθουν καμιά νέα γλώσσα κάποιοι κάποιοι, αυτό που πρέπει να πω είναι... για το 99% των περιπτώσεων, η αγορά τώρα θέλει αυτά που είπα παραπάνω: python, javascript, ruby και php. Είναι πιό εύκολες γλώσσες και γι'αυτό δεν τις διδάσκουν στο πανεπιστήμιο (γιατί θέλουμε να ακονίσουμε το μυαλό σας - όχι να σας καλομάθουμε από μικρά). Αυτό λοιπόν για εμένα είναι το μήνυμα για εδώ και τώρα.... Τώρα αν έχουμε σε 2 χρόνια τόσο λαό να ξέρει και να μη φοβάται αυτές τις γλώσσες και δω ένα post του στυλ "πώς μπορώ να προγραμματίσω PIC με Ruby;" θα είμαι ο πρώτος να πώ "ΕΙΣΑΙ ΤΡΕΛΟΣ ΡΕ ΦΙΛΕ";;; :D

Βαθειά ανάσα και ξεκινάμε... Μπααα... αν υποθέσουμε ότι έχουμε ένα project με συγκεκριμένες προδιαγραφές (π.χ. να κάνουμε έναν monte-carlo optimizer για κάποιον παραμετρικό δείκτη χρηματηστηρίου - βλέπεις - το παίζω και στην έδρα της C) και - για να είμαστε ρεαλίστικοι - έχουμε συγκεκριμένο budget (π.χ. 3000 ευρώ). Με την C θα ψοφήσεις να γράφεις for loops (με την ψευδαίσθηση ότι είναι και γρήγορες) και στο τέλος θα καλείς συναρτησούλες που έχουν for loops μέσα σε for loops... και αν είναι 100k δεδομένα είναι εντάξει - αλλά αν ήταν δεν θα πηρωνόμασταν 3000 ευρώ. Οπότε έχοντας π.χ. 3 for loops το ένα μέσα στο άλλο χωρίς καν να το ξέρουμε (η strlen είναι ήδη ένα), καταλήγουμε να έχουμε O(n^3) (οκ-μη βαράτε-απλά προσπαθώ να make a point) το οποίο π.χ. με 100Mb δεδομένα θα είναι αργό - πόσο μάλλον με 16 ή 160 Gb. Τώρα όταν με την python έχεις μία cache σε μία γραμμή (δες εδώ built-in δομές)... >>>> v="k" >>> upper_c={} >>> upper_c[v] = upper_c[v] if v in upper_c else v.upper() # Vale tin Argi sinartisi sou edo >>> print upper_c[v] ... είναι πιθανότερο να παραμείνεις κοντά στο O(n). Και τι να πει κανείς όταν με 3 γραμμές κώδικα (celery) και το Amazon (EC2) μπορώ να τρέξω μία συνάρτηση παράλληλα σε 160 μηχανήματα (=1Gb/μηχάνημα στο παραπάνω παράδειγμα) - (reduce? οκ-μη βαράτε-απλά προσπαθώ να make a point). Για να το έκανες αυτό σε C θα ήθελες άλλες 3 βδομάδες που δεν έχεις... Αν έχεις άπειρο χρόνο και χρήμα η C είναι πιό γρήγορη... αλλά πρακτικά... μπάαααα... python (django), javascript (jQuery και node.js), ruby (rails) Pascal δεν υπάρχει. ΠΑΡΑ ΠΟΛΥ ΑΡΓΗ (στο productivity). Η python πάει "σφαίρα". Σίγουρα θα τη βρίσκεις συνέχεια μπροστά σου 400 ευρώ αν είσαι επαγγελματίας τα "καθαρίζεις" σε 3-4 μέρες. (δες και http://www.pameekso.gr/ta-vasika-ergaleia για tips). 4000 ευρώ/μήνα τα έχεις με αρκετό άγχος και red bull Μακάρι να ξέραν τι κάνουν τα άτομα κι εκεί (δες εδώ/εδώ)... αλλά anyway... ναι - και χρησιμοποιούνε αρκετή java as well 100% ναί. Ubuntu και άγιος ο Θεός. Perl είναι λίγο κακή - εύκολο να τη γράψεις - δύσκολο να τη διαβάσεις Ωωωω ναι! Ωωωω ναι! Μια χαρά είσαι με την php. Δοκίμασε από βάσεις ένα project-άκι σε κάθε μία από τις εξής: mongodb, neo4j και redis. Δυστυχώς όχι... Η Java ήταν καλή επιλογή όταν είχες χρόνο να κάθεσαι να γράφεις κλάσεις και μλκίες. Το 2011 δεν έχεις χρόνο γι'αυτά. Δες εδώ ακριβώς τι εννοώ. Μη συγκρίνετε γλώσσες σε λάθος βάση. Ελάχιστοι επαγγελματίες γράφουν πια C. Δεν υπάρχει χρόνος - αλήθεια. Το μόνο πράγμα για να αξιολογήσεις σήμερα μία γλώσσα είναι productivity. Τίποτα άλλο. Αστειευόμενος ελαφρώς: >C: int i; for (i=0;i<10;i++) printf("Hello %d\n", i); Java: ObjectIterator i = collection.getObjectIterator(); while (i.hasNext()) { System.out.format("Hello %s\n", i.next().toString()); } Python: for u in users: facebook.createUser(u); Το μόνο metric για την ποιότητα του κώδικα είναι WTFs/m. Με την Ruby και την Python είναι πολύ δύσκολο να κάνεις λάθη και ο κώδικας είναι πολύ πιο εκφραστικός = χαμηλότερο WTFs/m. Τέλος αυτό που πάντα ΠΡΕΠΕΙ να κάνεις με τα προγράμματά σου για να επιβιώσεις είναι να μπορείς να κάνεις τον άλλον να κάνει WOW! Το WOW το '90 σήμαινε να παίζεις με το PC speaker και αυτό μπορούσες να το κάνεις με την Basic, το '00 σήμαινε να μπορείς να κάνεις κανένα productivity suite δηλαδή ξέρεις... το excelάκι - το e-mailάκι του κάθε επαγγελματία κ.τ.λ. Αυτό το έκανες με VBA, Java, C# κ.τ.λ. Σήμερα για να κάνει ο άλλος WOW πρέπει να έχεις social login, videos, integration με τηλέφωνο, να έχεις single click deployment στο cloud, να είναι socialy integrated, mobile, και φυσικά να είναι έτοιμο χθες. Ψάξτε λίγο τι γλώσσες παίζουν σε όλα αυτά τα links που λέω παραπάνω και θα δείτε ότι η C δεν υπάρχει. Έχει απλά τελειώσει και είναι θέμα χρόνου δυστυχώς μέχρι να μπει στο μουσείο (πέρα από linux device drivers και kernel hacking). Η php όχι μόνο δεν είναι νεκρή... αλλά ζει και βασιλεύει (παρόλο που δε μ'αρέσει, php=Personal Home Page - αυτό τα λέει όλα). Η Javascript θα σκάσει απίστευτα. Η Python είναι defacto όπως και η Ruby. Αυτή είναι η "επαγγελματική" πραγματικότητα σήμερα 2011-2012. Ξέρω πολύ καλούς pointers και μου δίνει καλό background και αυτοπεπίθεση... από την άλλη τώρα τελευταία όλο μου την βγαίνουν από τα δεξιά κάτι πιτσιρίκια που το μόνο που ξέρουν είναι Symfony και μαθαίνουν Python και google apps engine overnight. Εύχομαι αυτό το post να βοηθήσει πολλούς να σώσουν χρόνια.