Η Microsoft δίνει στο GitHub τον πηγαίο κώδικα του MS-DOS 4.0

[aroutis]

Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.

Παρά πολύ σωστά.

[chat1978]

Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.

Έχω πολλές διαφωνίες με τους μοντέρνους devs αλλά όχι αυτό. Επίσης η προτροπή αυτή, μου θυμίζει την διαφωνία μεταξύ managed και non managed runtime και σταματώ εδώ γιατί θα εμπλακούμε σε μεγάλο offtopic

[Mosfet]

Καλά θα κάνουν οι σύγχρονοι coders & devs να μην σπαταλούν αλόγιστα τα resources, θα έλεγα εγώ.

Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).

Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386.

[aroutis]

Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).

Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386.

Το ένα δεν ακυρώνει το άλλο. Το efficiency δεν έχει να κάνει με το τι κάνει ο κώδικας αλλά πως είναι γραμμένος.

[Mosfet]

Το ένα δεν ακυρώνει το άλλο. Το efficiency δεν έχει να κάνει με το τι κάνει ο κώδικας αλλά πως είναι γραμμένος.

Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;

Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.

Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.

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

[chat1978]

Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;

Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.

Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.

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

Δεν ήθελα να βγω offtopic αλλά σαν επαγγελματίας του χώρου, προτιμώ οτιδήποτε δεν θα σκοτώσει τον σέρβερ, ή το process γιατί πρώτα από όλα efficiency. Αν δεν είχαν υπάρξει τα managed runtimes και σε κάποιο βαθμό οι πιο εύκολες γλώσσες, internet δεν θα υπήρχε ποτέ και ούτε cloud. Δεδομένου του πως τα περισσότερα process γίνονται περιοδικά recycle και γενικά κλωνοποιουνται, το πρόβλημα δεν είναι τόσο η σπατάλη του developer όχι οι προσδοκίες που έχουν δημιουργήσει το λεγόμενο micro service architecture. Πάρε ένα k8s cluster που σηκώνει το runtime 500χιλ φορές για να τρέξει την πιο απλή εφαρμογή του κόσμου.

Και μιας και βγήκα offtopic το πρόβλημα που προσωπικά έχω είναι η σχεδόν παντελης άγνοια και αδιαφορία που καλλιεργείται για το που τρέχει ο κώδικας vm,os, process, thread και γενικά για το production και η γενικότερη προώθηση του λεγόμενου developer architecture.

[Tzitziloni]

Πολύ γενικόλογο αυτό που αναφέρεις. Και στο γράφει αυτό, ένας που είναι το επαγγέλματος (software developer γαρ).

Το ισχυρότερο hardware, βγαίνει για να τρέχει σε αυτό σύγχρονο (και βαρύτερο) software. Το σύγχρονο software είναι βαρύτερο, γιατί προφανώς κάνει πολύ περισσότερα πράγματα από το software που είχε βγει λ.χ. πριν από 30 χρόνια. Αλλιώς, θα είμασταν όλοι, ακόμα με 386.

Δεν κάνει πάντα περισσότερα ούτε αυτό πρέπει να αποτελεί δικαιολογία. Όπως και να έχει, πρέπει να είναι προσεκτικά γραμμένο. With great power comes great responsibility, δεν λένε; Ισχύει και σε αυτή την περίπτωση.

- - - Updated - - -

Efficiency ως προς τι; Ως προς την ταχύτητα εκτέλεσης, ως προς την μνήμη, ως προς το I/O;

Δεν είναι έτσι απλά τα πράγματα, καθώς όπως καταλαβαίνεις παίζουν πολλοί παράγοντες ρόλο. Άλλωστε, όσο πιο πολύπλοκος γίνεται ο κώδικας, τόσο δυσκολότερο είναι να γίνει και πιο efficient.

Επίσης, μην ξεχνάμε το maintainability του κώδικα. Αν είναι π.χ. να γίνει ο κώδικας υπερβολικά πολύπλοκος και στρυφνός (aka spaghetti), προκειμένου να τρέχει λ.χ. 5% πιο γρήγορα, ώστε να δουλεύει επαρκώς γρήγορα και σε παλιότερα συστήματα, τότε η συντριπτική πλειοψηφία των devs, μαζί και εγώ, απλά δεν πρόκειται να το κάνει.

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

Η υπερβολική βελτιστοποίηση της απόδοσης είναι edge case -δεν αναφέρομαστε σ' αυτό, νομίζω. Ο κώδικας πρέπει να είναι απλός, καλογραμμένος και να μην "σπαταλάει" άδικα resources. Πολύ βασικό αλλά όχι εύκολο. Καταρχάς ο απλός κώδικας είναι κάτι δύσκολο από μόνο του και έρχεται μόνο με την εμπειρία. Ακολουθεί η "κακή" χρήση των frameworks τα οποία παρέχουν πολλά by default αλλά αν θες το αποτέλεσμα να είναι γρήγορο και scalable, πρέπει να ξέρεις τι σου γίνεται.

- - - Updated - - -

Και μιας και βγήκα offtopic το πρόβλημα που προσωπικά έχω είναι η σχεδόν παντελης άγνοια και αδιαφορία που καλλιεργείται για το που τρέχει ο κώδικας vm,os, process, thread και γενικά για το production και η γενικότερη προώθηση του λεγόμενου developer architecture.

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

[NeK]

Συμφωνώ με τον chat και τον Tzitziloni.

Το σημερινό software γίνεται ολοένα και περισσότερο pessimized (το αντίθετο του optimized) και υπερκαταναλώνει αδικαιολόγητα υπέρογκα resources. Ναι μεν δεν πρέπει να κάνεις premature optimization, αλλά προσπάθησε να μην κάνεις το αντίθετο, δηλαδή να μην το κάνεις πολύ αργό/μνημοβόρο/ioβορο χωρίς λόγο. Θα πρέπει καθώς γράφεις κώδικα να τηρείς το non-pessimization. Δηλαδή να γράφεις κώδικα που δεν καταναλώνει πολύ περισσότερα cpu/mem/io resources από όσα χρειάζεται (στο περίπου), έχοντας στο νου σου στο περίπου τι overhead μπορεί να έχει το κάθε τι που γράφεις. Αυτός είναι καλός κώδικας. Αλλα χρειάζεται να είσαι καλός προγραμματιστής για να έχεις αυτή την γνώση να τα αντιλαμβάνεσαι αυτά. Τα εξηγεί πολύ ωραία ο Casey Muratori στο:

[chat1978]

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

Χρόνια τώρα, μόλις δούλεψα με άτομα που δεν είχαν εμπειρία εκτός on-premise και εφαρμογές που πουλιούνται στον πελάτη και τρέχουν για καιρό.

Αλλά αναρωτιέμαι μήπως γινομαι λίγο σαν τους C++σιστές της γενιάς μου όταν ξεκιναγα και το αστείο ήταν ότι και εγώ από εκεί ερχόμουν σνομπάροντας το managed runtime.

[MNP-10]

Μπορεί τα παιχνίδια να ήταν pixelated, αλλά έπαιρναν άριστα στο gameplay. Σε έκαναν να σκέφτεσαι και να κολλάς με το παιχνίδι ακόμα και τις ώρες που ήσουν εκτός και δεν το έπαιζες.

Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο. Σημερα δεν υφισταται η εννοια της εφαρμογης ή του game σε τελικη κατασταση. Ειναι λες και αγοραζεις alpha h beta προγραμματα και κανεις real-time debugging. Στην ουσια πρεπει να αποδεχτεις οτι αγορασες κατι ημιτελες με απειρα bugs που θελουν συνεχες patching εις το διηνεκες.

[goku]

Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο.

Και παλιά υπήρχαν DLC σε παιχνίδια, φυσικά δεν ήταν τόσο διαδεδομένα όσο είναι σήμερα. Επίσης κυκλοφορούσαν και patch για διόρθωση τυχών bugs. Κάτι που θεωρώ ότι είναι πολύ διαφορετικό το παλιό σε σχέση με το καινούριο είναι ότι έπαιρνες το παιχνίδι σε CD/DVD, το έκανες εγκατάσταση και απλώς έπαιζες. Τώρα πολλά παιχνίδια δεν κυκλοφορούν καν σε δισκάκι, αλλά και να τα βρεις σε δισκάκι θα πρέπει να κάνεις λογαριασμό στο Steam και να το ενεργοποιήσεις πρώτα με τον σειριακό που θα είναι μέσα στο κουτί. Και το δισκάκι είναι απλώς backup του παιχνιδιού, το οποίο αν δεν είναι ενημερωμένο ενδεχομένως να κατεβάσει και κάποια patch που αναλόγως και το παιχνίδι δεν αποκλείεται να είναι από μερικά KB μέχρι και κάμποσα GB (στην ουσία μπορεί να χρειαστεί να ξανακατεβάσει το παιχνίδι από την αρχή οπότε το backup είναι άχρηστο). Επίσης από την στιγμή που το κλειδί το εισάγεις στον λογαριασμό σου στο Steam, η κόπια που έχεις χάνει οποιαδήποτε αξία μεταπώλησης μιας και το κλειδί δένεται με τον προσωπικό σου λογαριασμό και δεν μπορείς να το δώσεις σε άλλον, ενώ παλιά που ήταν σε δισκάκια, η ίδια κόπια μπορεί να άλλαζε και 50 χέρια, εγώ προσωπικά θυμάμαι είχα αγοράσει ένα παιχνίδι όταν ήμουν πρωτοετής στην σχολή μου και είχε γυρίσει όλο το τμήμα μου, το είχα δανείσει σε όλα τα παιδιά.

[chat1978]

Επισης κατι που ειναι αδιανοητο σημερα: Αγοραζες ενα game ή εφαρμογη και ηταν το τελικο προϊον. Αν τυχον ειχε καποιο προβλημα θα το ειχε μαθει το συμπαν και θα εκραζαν την εταιρια οτι εβγαλε κατι προβληματικο. Σημερα δεν υφισταται η εννοια της εφαρμογης ή του game σε τελικη κατασταση. Ειναι λες και αγοραζεις alpha h beta προγραμματα και κανεις real-time debugging. Στην ουσια πρεπει να αποδεχτεις οτι αγορασες κατι ημιτελες με απειρα bugs που θελουν συνεχες patching εις το διηνεκες.

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

Προσωπικά δεν συμφωνώ όταν το ξεσκίζουν το θέμα, βλέπε r1 κτλ

[MNP-10]

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

Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.

[Mosfet]

Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.

Από την μία πλευρά έχεις το πολύ γρήγορο internet, που κάνει εύκολο και γρήγορο το distribution των patches και από την άλλη πλευρά, έχεις τους διάφορους μανατζαρέους που θέλουν πάση θυσία να πιάνουν τα milestones (και να καρπώνονται τα bonuses βεβαίως-βεβαίως), βγάζοντας releases εμφανώς μη επαρκώς τεσταρισμένες και τίγκα στα issues.

Και οι 2 παράγοντες, προφανώς οδηγούν σε μια FUBAR κατάσταση.

[chat1978]

Για το πιο πολυπλοκο προϊον ισχυει αλλα τα σημερινα release cycles ειναι πολυ πιο αργα, ειδικα στα λειτουργικα της MS. Μπορει να θελει 3-5 χρονια για νεα εκδοση windows αλλά με το καλημερα ειναι γεματη bugs και προβληματα.

Δεν θα συμφωνήσω και εξαρτάται τι θεωρείται πραγματικά new version. Και ποια κομμάτια αντιλαμβάνεσαι εσύ ως νέα.

Πχ στα Vista έγινε refactor όλο το graphics subsystem χωρίς όμως να δει κάτι ο χρήστης.

Χωρίς να το ψάχνω τόσο πολύ πια, για μένα βγάζει σοβαρό service pack κάθε 6 ή 12 μήνες. Στα xp ή στα vista θυμάσαι; Πόσο καιρό πήρε να σταθεροποιηθεί το core μαζί με τους drivers. Τότε δεν είχανε και όλοι broadband να κατεβάζουμε windows update με τα τσουβαλια.

Τώρα τα 11 με τα 10 με το latest release λίγη διαφορά είχαν με εξαίρεση το αισθητικό. Μαρκετινγκ ήταν. Συνεπώς δεν μετράω χρόνια διαφοράς.

Τώρα αν θες να μείνεις στην Wikipedia και στα official release dates τότε θα έχεις δίκιο αλλά για μένα θα συγκρίνεις ανόμοια πράγματα που είναι και λίγο χαρακτηριστικό αυτής της επιχειρηματολογίας.