Παραθέτω ενα κειμενάκι που βρήκα στο νετ:

For awhile, the main competitor to Java applets was Microsoft’s ActiveX, although it required that the client be running Windows. Since then, Microsoft has produced a full competitor to Java in the form of the .NET platform and the C# programming language. The .NET platform is roughly the same as the Java virtual machine and Java libraries, and C# bears unmistakable similarities to Java. This is certainly the best work that Microsoft has done in the arena of programming languages and programming environments. Of course, they had the considerable advantage of being able to see what worked well and what didn’t work so well in Java, and build upon that, but build they have. This is the first time since its inception that Java has had any real competition, and if all goes well, the result will be that the Java designers at Sun will take a hard look at C# and why programmers might want to move to it, and will respond by making fundamental improvements to Java.

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

---

Oh man.....I have no idea
what's going on......

Η Java έχει κάποια σχεδιαστικά σφάλματα, τα οποία είναι μάλλον αδικαιολόγητα (κατά τη γνώμη μου). Μερικά τα οποία θυμάμαι τώρα, είναι



1) Οι methods μιας κλάσης είναι εξ' ορισμού virtual. Ιδιαίτερα αρνητικό κατά τη γνώμη μου.

2) Είναι αργή ως πλατφόρμα. Στα generics για παράδειγμα, ο compiler μετατρέπει τον τύπο σε Object πχ. ένα List, όταν γίνει compiled αλλάζει σε List, με αποτέλεσμα να χάνεις τον μπούσουλα στο reflection, και να χάνεις σε ταχύτητα λόγω type castings.

3) Αν και παρουσιάζεται ως multi-platform, εν τούτοις τα πράγματα δεν είναι τόσο απλά όσο Write, Complie, Run at any, καθώς χρειάζεται ειδική μεταχείριση για κάθε target πλατφόρμα.

4) Οι τύποι των δεδομένων έχουν διαφορετική μεταχείριση, ανάλογα με το αν είναι value types και reference types. Αυτό είναι και ένα από τα μεγαλύτερα ατού του .net framework, καθώς τα πάντα κληρονομούν από το object (και πιστεύω πως έχουν γλυτώσει αρκετούς από εμάς, από πονοκεφάλους).

5) Το .net φτιάχτηκε με εγγενή υποστήριξη της XML, ενώ στη Java, προστέθηκε ως plugin/update. Φυσικά, η XML δεν είναι πανάκεια για κάθε πρόβλημα, αλλά η ύπαρξή του από την αρχή, είναι πολύ καλύτερη από οποιοδήποτε είδους retrofitting.

6) Η πρόοδος, θα έλεγα ότι μάλλον είναι από τα μειονεκτήματα της Java. Δεδομένης της πολύ μεγαλύτερης ηλικίας της, όχι μόνο δεν έχει καταφέρει να εξελιχθεί σε κάτι περισσότερο από browser/cellphone plugin, αλλά δεν έχει κάνει και αξιόλογα τεχνολογικά βήματα. Για το .net από την άλλη, δες τι ετοιμάζεται στην έκδοση 3.0.


Αυτά, αν και φαντάζομαι ότι υπάρχουν περισσότερα, όπως και το ότι κάποια χαρακτηριστικά της Java θα ήταν επιθυμητά στην C# και το .net (πχ throws).

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Ο μεγαλύτερος αντίπαλος των Java applets ήταν πάντα ο τελικός χρήστης που δεν είχε όρεξη να κατεβάζει το runtime και τα applets!Εγώ θα έλεγα ότι στον χώρο των applets έχασε και το ActiveX και η Java καθώς όλοι τρέχουν να τις αντικαταστήσουν με AJAX!

Για σκέψου, Java applets βρίσκεις πλέον μόνο σε αρχαία sites για τη δημιουργία μενού ή εφέ που μπορούν να γίνουν και με Javascript ή, πολύ καλύτερα, με Flash. Το ίδιο και με τα ActiveX.

Όσο για το κλισέ "αντιγράψανε το ΧΨΖ και το βελτιώσανε", αυτό λέγεται πρόοδος. ΌΛΕΣ οι σύγχρονες γλώσσες έχουν αντιγράψει στοιχεία η μία από την άλλη. Καμμία δεν δημιουργήθηκε σε κενό αέρος. Εξάλλου, πολλά από τα "αντιγραμμένα" στοιχεία πρωτοεμφανίστηκαν σε ακαδημαϊκές έρευνες και πειραματικές γλώσσες πριν περάσουν στις γνωστές γλώσσες. Άλλα χαρακτηριστικά προϋπήρχαν όλων των "in" γλωσσών που χρησιμοποιούμε σήμερα.

Παραδείγματα: Virtual Machine, sandbox, bytecode, generics και interfaces. Η ιδέα προέρχεται από τη Smalltalk, μία από τις πρώτες object-oriented γλώσσες. Η Smalltalk μάλιστα είχε και ένα άλλο χαρακτηριστικό που δεν υπάρχει σε άλλη γλώσσα. Το runtime και οι εφαρμογές αποθηκεύονταν στο δίσκο έτσι ώστε να ξαναξεκινήσει η εφαρμογή από εκεί που είχε μείνει! Ό,τι ακριβώς συμβαίνει όταν ένα PC κάνει hibernate.

Άλλο παράδειγμα. Το Javaspaces, ένα API που φτιάχτηκε για την επικοινωνία μεταξύ τους "έξυπνων" συσκευών με Java, ουσιαστηκά ήταν η τεχνολογία Linda της IBM για την απλοποίηση της εκτέλεσης προγραμμάτων σε πολλούς επεξεργαστές.

Άλλο παράδειγμα. Η Java κατάργησε τους function pointers της C λόγω περιπλοκότητας, με αποτέλεσμα να μας "κόψει τα πόδια". Η λύση ήταν να χρησιμοποιούνται χειροποίητα functor objects (ο όρος προέρχεται από τη C++). Το .NET λύνει το πρόβλημα των function pointers και κάνει τη λύση μέρος της γλώσσας.

Άλλο παράδειγμα. Το contract-based programming ξεκίνησε με την Eifell και τον Bertrand Meyer. Οι ιδέες αυτές αναφέρονται σαν αρχές και patterns τόσο στη Java  όσο και στο .NET, χωρίς όμως να υπάρχουν οι υλοποιήσεις τους όπως στην Eifell. Βλέπεις, η Eifell είναι σχετικά νέα γλώσσα (~15 ετών) και ισχύουν ακόμα οι πατέντες!

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

Αν θες τη γνώμη μου πάντως για το ποιό ήταν το μεγαλύτερο πρόβλημα της Java, ήταν ακριβώς η προσπάθεια να είναι cross-platform χαραμίζοντας τις δυνατότητες των λειτουργικών. Αυτό ίσως να είχε σημασία για την Sun και τις άλλες εταιρείες Unix όταν πρωτοβγήκε η Java, καθώς κανείς τους δεν υλοποιούσε 100% τα standard (Posix, XWindows κλπ). Για τους κοινούς θνητούς όμως που έχουμε απλά PC, δεν υπήρχε κανένα όφελος. Ίσα-ίσα, οι πρώτες εφαρμογές ήταν κακάσχημες, πολύ βαριές και αργές. Άσε που για να καταφέρεις να φτιάξεις μια φόρμα με μερικά κουμπιά έπρεπε να φτύσεις αίμα! Και σαν τίμημα για την (περιττή) συμβατότητα, έπρεπε να εγκαταλείψουμε το graphics acceleration, το DirectX (3D, audio), το file security και ένα κάρο άλλα πράγματα που υπήρχαν στα Windows αλλά δεν τα εκμεταλλευόταν η Java. 

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Το πρόβλημα με το throws είναι ότι είναι ... μπελάς, καθώς σε αναγκάζει να χειρίζεσαι exceptions που μπορεί να προέρχονται από άσχετο κώδικα (π.χ. βιβλιοθήκες τρίτων) ή να τις ξαναρίχνεις. Η κοινή λύση φυσικά είναι να κολλήσεις ένα throws Exception και καθάρισες!

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



Να προσθέσω και μια άλλη μεγαλη διαφορά μεταξύ Java και .NET. Η Java δημιουργεί bytecode, το οποίο είναι ουσιαστικά object-oriented assembly. Το .NET δημιουργεί μια ενδιάμεση μορφή του κώδικα, όπως ακριβώς κάνουν όλοι οι compilers πριν δημιουργήσουν τον τελικό κώδικα. Ένας compiler όμως πρέπει να κάνει κάποιες παραδοχές την ώρα του compilation, με αποτέλεσμα ο τελικός κώδικας να μην είναι ο καλύτερος για κάθε πλατφόρμα. Το .NET όμως αφήνει το τελευταίο βήμα στο runtime, επιτρέποντας έτσι τη δημιουργία του καλύτερου εκτελέσιμου κώδικα για την πλατφόρμα στην οποία εκτελείται.

Για παράδειγμα, το runtime μπορεί να δημιουργήσει διαφορετικό εκτελέσιμο κώδικα για πολλαπλασιασμούς πινάκων ανάλογα με το αν o επεξεργαστής υποστηρίζει MMX, SSE, SSE2, 3D Now κλπ. Ή να δημιουργήσει διαφορετικό κώδικα συγχρονισμού ανάλογα με το αν ο επεξεγραστής είναι single-core, multi-core, ή χρησιμοποιείται αρχιτεκτονική NUMA. Ειδικά στο θέμα του concurrency αναμένονται τεράστιες εξελίξεις, καθώς σύντομα θα βρεθούν όλα τα PC να έχουν παράλληλους επεξεργαστές!

Και το Java runtime μπορεί να εκμεταλευτεί τις δυνατότητες του κάθε επεξεργαστή, ως ένα σημείο όμως. Ο λόγος είναι ότι κατά την τελευταία φάση της δημιουργίας του bytecode ο Java compiler έχει κάνει αναγκαστικά κάποιες παραδοχές οι οποίες μπορεί να μην ισχύουν στον υπολογιστή που θα εκτελεστεί η εφαρμογή.

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Δεν έχεις άδικο σε ό,τι αφορά το throws. Έπρεπε να τονίσω βέβαια πως θα το ήθελα καθαρά από συντακτικής και όχι σημαντικής πλευράς. Δηλαδή, να υπάρχει στο method signature και μόνο. Τουλάχιστον, στις βιβλιοθήκες της Microsoft, το documentation είναι ικανοποιητικό σε ό,τι αφορά τα exceptions, καθώς και η υποστήριξή τους στα XML comments.



...



Βέβαια, αυτό που _πραγματικά_ θα ήθελα, ήταν να ενσωματωθεί η SpeC# στην C#. Όσο διαβάζω, τόσο περισσότερο γίνομαι οπαδός του Aspect Oriented Programming.

---

Μην αφήνετε τα media να σας "ταΐζουν"!

Ενδιαφέρουσα σχόλια. Μόνο που το .Net και η C# τρέχουν σε άλλες πλατφόρμες πέρα από τα Windows?

Η Sun δίνει JRE για Windows, Mac os X, Solaris (x86 και Sparc) και Linux.

H ΙΒΜ δίνει δικό της JRE για Linux, AIX και για αρχιτεκτονικές x86 και PPC32/PPC 64

Το Mono υπόσχεται πολλά αλλά θα πετύχει το cross platform των .ΝΕΤ εφαρμογών;

Με applets κανένας πια δεν ασχολείται, ούτε η Sun.

Πιο πολύ ασχολούνται με J2EE, EJB, JSP.

Πάντως το καλό είναι ότι υπάρχει μεγάλος ανταγωνισμός και βελτιώνονται τα εργαλεία. Για παράδειγμα δεν έχει προλάβει να βγει η Java 5, να βγουν βιβλία για αυτήν την έκδοση και να κάνουν migrate κώδικα και η Java 6 είναι σχεδόν έτοιμη. Ακόμα η Sun δίνει δωρεάν το Java Studio enterprise 8 που πριν το πουλούσε 2000 $.

---

Powered by openSuSE 11 64-bit Edition

pkanavos wrote:

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

...και τους ανάγκασε να κάνουν Try...Catch ex As Exception...End Try σε οτιδήποτε μπορεί ή δεν μπορεί να πετάξει οποιουδήποτε είδους exception :)

(EDIT: Ουχ, VB.NET-ικά το έγραψα, αλλά το πιάσατε το νόημα πάντως ε; :) )

Εγραψα σε Java για ένα φεγγάρι (πολύ λίγο) και αυτό που μου έλειψε όταν είδα .NET ήταν το throws. Υπήρχε μεγάλη συζήτηση πίσω από την επιλογή της Microsoft να μην το χρησιμοποιήσει τελικά, δεν ξέρω αν έκανε λάθος ή σωστά μια και με οποιαδήποτε από τις δύο προσεγγίσεις αναγκάζεσαι για να καλυφθείς να κάνεις πράγματα. Ισως, το μονο που μπορώ να χαρακτηρίσω σαν πλεονέκτημα στο .NET είναι οτι η έλλειψη του throws σε αφήνει ελεύθερο να ΜΗΝ χειριστείς πιθανά exceptions (και να τα φας πιθανώς στο runtime, όμως το οτι σου επιτρέπει να διαλέξεις τι θέλεις να κάνεις είναι σημαντικό, όπως και να το κάνουμε).

 

 

---

Σωτήρης Φιλιππίδης

DotSee Web Services

Εγώ ξεκίνησα ανάποδα από java και πήγα σε .ΝΕΤ και C#.



Όπως το είδα εγώ, η .ΝΕΤ είχε πολύ περισσότερα εργαλεία out of the box, ενώ η java στηριζότανε πάρα πολύ σε κοινότητες οpen source.

Για .ΝΕτ επίσης τεράστιο πλεονέκτημα είναι το Visual Studio. Κάτι είχε κάνει βέβαια και η Sun με το Sun One Studio (τότε, τώρα δεν ξέρω πως το ονομάζει).

Γενικά όπως το είδα με το .ΝΕΤ είναι πιό εύκολα όλα.

Όσο για C# και Java, με την έκδοση 5 πιστεύω ότι η java κάλυψε μεγάλο μέρος της διχάλας, ενώ με την 6 θα καλύψει ακόμη περισσότερο.

Για εμπορικές εφαρμογές όμως, τα πάντα παίζονται στα έτοιμα ΑΡΙ που δίνουν, και στα οποία φαίνεται να υπερέχει το .ΝΕΤ έχοντας ενσωματώσει τα πάντα σε ένα ενιαίο, σε αντίθεση με την java που πρέπει να κατεβάσεις 10 διαφορετικά SDK.

---

Simple Photography

Η αλήθεια είναι πως, όταν η Microsoft πήγε στην ECMA για την κατοχύρωση της C#, και τη μηδενική της αντίδραση για το Mono & dotGnu, ήθελε (και θέλει) πάρα πολύ η ιδέα του .net framework να επεκταθεί και στις άλλες πλατφόρμες, χωρίς φυσικά να το διατυμπανίσει ανοιχτά. Δεν πιστεύω ότι θα αφήσει ανεκμετάλλευτη την όποια επέκταση του .net στο μέλλον.


Τώρα, όσον αφορά τα features της Java 6, ομολογώ ότι ορισμένα πράγματα όπως αυτό: http://weblogs.java.net/blog/campbell/archive/2006/01/400_horsepower.html, δείχνουν σχεδιαστικά σφάλματα (yet another demonstration of the evils of finalizers and explicit System.gc() calls), τα οποία έπρεπε να είχαν αποφευχθεί από την αρχή. Η κατάσταση βέβαια δεν είναι τόσο άσχημη όσο με την PHP (όπου για παράδειγμα, είχαν αφαιρέσει ένα feature από μία έκδοσή της, χωρίς να το κάνουν deprecate σε προηγούμενο build, αλλά το επανέφεραν ορισμένα builds αργότερα!).

Άραγε, σε πράγματα όπως το LCD antialiasing, θα χρησιμοποιούν τη native υποστήριξη από το λειτουργικό όπου αυτή υπάρχει, ή θα είναι δική τους λύση, ενδεχομένως και κακοπρογραμματισμένη; Και φυσικά, για το Splash screen που αναφέρεται, δε θα κάνω (σχεδόν) κανένα σχόλιο (πολύ... σημαντικό feature!).


Γενικώς, η Java θα σώζονταν από ένα total rewrite, και ίσως έτσι να μπορούσε να συναγωνιστεί πιο άμεσα το .net framework. Αλλά φυσικά αυτό δεν πρόκειται να γίνει ποτέ. Ρίξτε μια ματιά στην VB.Net 9.0. Πράγματα όπως τα Dynamic interfaces, Relaxed Delegates και Anonymous types, επαναφέρουν τους... "μπαμπούλες" της VB6. Γιατί άραγε; Ορίστε ορισμένα σχόλια:
http://www.developersdex.com/vb/message.asp?p=1121&r=4822469

---

Μην αφήνετε τα media να σας "ταΐζουν"!

dimkasta wrote:

Όσο για C# και Java, με την έκδοση 5 πιστεύω ότι η java κάλυψε μεγάλο μέρος της διχάλας, ενώ με την 6 θα καλύψει ακόμη περισσότερο.

Και με την C# 3, η διχαλα θα ξανα-μεγαλωσει παλι...Η Java εχει αποτυχει, και μαλιστα οικτρα, σε οτιδηποτε εχει να κανει με το client κομματι. Ειναι τοσα χρονια στην αγορα και χρησιμοποιειται ακομα σε server based applications. Επισης, ειχε και πολυ λαθος timing: Οταν αρχισε τα πρωτα (και οχι μονο) βηματα της, τα μηχανηματα που υπηρχαν τοτε δυσκολευοντουσαν ακομα και να εμφανισουν στην οθονη μια κενη φορμα. Και δεν μιλαω για τα javo-εργαλεια, οποιος ειχε δουλεψει πριν το 2000 το π.χ. JBuilder θα καταλαβει τι εννοω. Το .net βγηκε σε μια περιοδο οπου οι επεξεργαστες και οι μνημες βρισκονταν σε τετοιο σταδιο που μπορουσαν να το "παρακολουθησουν" και αρα να γινει ελκυστικο στους προγραμματιστες. Η Java μπορει να ειχε αλλη καταληξη/πορεια αν η Sun δεν ηθελε να εχει τη μονοκρατορια επανω της και ειχε συνεργαστει με την IBM.

---

Software Engineer, specializes in Microsoft .net/C#, COM, Sql Server and now Python.

thrylos wrote:

Ενδιαφέρουσα σχόλια. Μόνο που το .Net και η C# τρέχουν σε άλλες πλατφόρμες πέρα από τα Windows? Η Sun δίνει JRE για Windows, Mac os X, Solaris (x86 και Sparc) και Linux. H ΙΒΜ δίνει δικό της JRE για Linux, AIX και για αρχιτεκτονικές x86 και PPC32/PPC 64

Έχεις δει πολλά τέτοια μηχανήματα σε εταιρείες? Πέρα από τα AS/400 δηλαδή. Το 90% των μηχανημάτων που συναντάει κανείς έχουν Intel επεξεργαστές, τα υπόλοιπα είναι Mac/PowerPC. Και δεν νομίζω ότι ένας χρήστης Mac θα δεχόταν ποτέ ένα Java UI στο dekstop του ...

Όταν ξεκίνησε η Java στόχευε το dekstop, όχι το server. Βέβαια, με το φρικαλέο UI και το εξαιρετικά δύσχρηστο Java Studio (1998), εξασφάλισε την παταγώδη αποτυχία της. Αν θυμάσαι, εκείνη την περίοδο η Microsoft έβγαλε το JFC το οποίο συνέφερε το UI ενώ HP, IBM, Microsoft έβγαζαν η καθεμία τη δική της VM για να αντιμετωπίσουν την κακή απόδοση. Έτσι τουλάχιστον αναγκάστηκε η Sun να βγάλει το Swing και να βελτιώσει το JRE. Όσο για το Studio, πήρε μαθήματα ευχρηστίας από τη Visual Basic, τη Visual J++ και τη Delphi και σουλουπώθηκε. Δεν χρειάζεται πλέον να φτήνεις αίμα για να φτιάξεις μία φόρμα που θα φαίνεται ίδια σε όλα τα VM! Ααααχ, ακόμα θυμάμαι τα Network Computers και τα Java PCs, τα οποία έβγαιναν με 32 MB μνήμη στην μεγαλύτερη έκδοση "γιατί δεν χρειαζόταν περισσότερο". Καθώς και ότι το 1998 το καλύτερο πρόγραμμα για να σχεδιάσεις μια φόρμα Java ήταν η ... J++!

Εν συντομία, τί με νοιάζει αν η εφαρμογή μου παίζει στο 1% της αγοράς, το οποίο δεν θα την αγόραζε έτσι κι αλλιώς? Πρέπει να δυσαρεστήσω το 90% των πραγματικών πελατών μου γι αυτό?

Για τους server τώρα. Αφού απέτυχε στο dekstop, η Java κοίταξε τους Server. Ή μάλλον, αφού η Sun αποφάσισε ότι δεν θα κατάφερνε να μπει στην αγορά των desktop, ας κοιτάξει τους servers και το Solaris. Εκεί έχει πάτημα, καθώς οι μεγάλες εταιρείες έχουν Solaris, AS/400, AIX και παραλλαγές. Βέβαια έπρεπε να πεθάνει το CORBA για να ξεκινήσει η ιστορία του J2EE ενώ οι τιμές των Application Server ήταν στην αρχή αστρονομικές. Κάτι προγραμματάκια όπως το Tuxedo ζητούσαν δεκάδες μύρια πριν από μερικά χρόνια ανά επεξεργαστή.
Και ΤΣΟΥΠ! Η Microsoft δίνει ένα τσάμπα Application Server με τα Windows NT 4 και τον MTS! Out of the box! Χωρίς διαδικασίες εγκατάστασης διαρκείας ημερών! Πανικός! Να έβλεπες πως κατρακυλήσανε οι τιμές των App Servers σε περιβάλλον Windows! Think Stuka σε κάθετη εφόρμηση! Βέβαια, στα *nix οι τιμές παραμείνανε στρατοσφαιρικές, αλλά θα μου πεις, από αστρονομικές που ήταν ...
Έπρεπε να βγουν ανεξάρτητες εταιρείες που έβγαλαν προϊόντα όπως το JBoss για να συμμαζευτεί η κατάσταση και στα *nix. Βλέπεις, η Java είναι απλά η γλώσσα με την οποία επικοινωνείς με το server ή το Transaction Processing Monitor. Όλη η αξία είναι στο ίδιο το TPM και πριν το JBoss αυτά κόστιζαν μύρια. Και τα παλαιότερα app servers είχαν Java API αλλά δεν είχαν πιάσει. Ή μάλλον, είχαν πιάσει σε λεφτά που πλήρωνε ο πελάτης, δεν είχαν πιάσει σε εγκαταστάσεις. Όταν χρειάζεται να πληρώσεις 200 μύρια για 4 επεξεργαστές, ε, δεν αγοράζεις και πολλά licenses!
Με server σαν το JBoss πλησιάζουν τώρα και οι άλλες πλατφόρμες αυτό πουτα Windows είχαν για 7 περίπου χρόνια: Τσάμπα application server. Δεν λέω η Java, γιατί σημασία δεν έχει η γλώσσα αλλά ο server. Αυτός είναι εξάλλου και ο λόγος που το J2EE δεν είναι και τόσο "standard" όσο θα ήθελε η Sun. Ο κάθε server έχει τα δικά του χαρακτηριστικά τα οποία δεν καλύπτονται από τα specs του J2EE.

 

Νομίζω πάντως ότι βγήκαμε εκτός θέματος. Το θέμα δεν ήταν αν είναι καλό ή κακό το cross-platform αλλά ποιά στοιχεία δανείζεται η μία γλώσσα από την άλλη. Θυμήθηκα άλλο ένα ωραίο.
Threads! Τα threads εμφανίστηκαν στην Ada και πέρασαν στις υπόλοιπες γλώσσες και τελικά επηρέασαν και τη σχεδίαση των ίδιων των επεξεργαστών! Μόνο που από την Ada οι υπόλοιπες γλώσσες δανείστηκαν μόνο την έννοια των threads και όχι τους υπόλοιπους μηχανισμούς συγχρονισμού και scheduling.

Τώρα πάντως που το concurrency αρχίζει και πονάει, θα αρχίσουμε να ακούμε για coroutines, transactional memory, lock-free programming. Χαρακτηριστικά που υπάρχουν ήδη σε ακαδημαϊκές γλώσσες ή συζητούνται στις C/C++ αλλά θα περάσουν σιγά-σιγά και στις γλώσσες γενικής χρήσης.

Α, και ένα ακόμα χαρακτηριστικό το οποίο θα ήταν ωραίο να ξαναμπεί κάποια στιγμή στις κύριες γλώσσες. Κάποιες παλιές εξειδικευμένες γλώσσες όπως η APL είχαν ειδικούς τελεστές για πράξεις πινάκων (πολλαπλασιασμούς, διακρίνουσες κλπ). Θα ήταν ωραίο να ξαναμπούν αυτά στη ζωή μας, με αυτόματη εκμετάλευση των εντολών MMX, SSE κλπ!

Υ.Γ. Υπάρχει έκδοση της APL για .NET, http://www.dyalog.com και http://www.apl2000.com

Υ.Υ.Γ. Σε τελική ανάλυση, το ζουμί της κουβέντας δεν είναι ποιά γλώσσα αντέγραψε από ποιά, αλλά το ότι δεν υπάρχει μία γλώσσα που να τα κάνει όλα. Νέα χαρακτηριστικά γεννιόνται συνέχεια σε κάθε γλώσσα και μεταφέρονται στις άλλες. Όσο περισσότερες γλώσσες ξέρει κανείς τόσο ευκολότερα κάνει τη δουλειά του. Απλά και μόνο αντιγράφοντας κόλπα από τη μία στην άλλη

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Τι θέλω και το ανοιγω? :D

Εχασα την μπάλα με όλα αυτα.....:$

---

Oh man.....I have no idea
what's going on......

Παναγιώτη εγώ όταν μίλησα για PPC32/64 δεν είχα μόνο στο μυαλό μου τα desktops της apple. Κυρίως είχα τους νέους servers της IBM που έχουν τον Power 5 και τρέχουν AIX 5L ή Linux.

---

Powered by openSuSE 11 64-bit Edition

Αυτό θα πει ξεθάβω thread.

Θα αναφέρω κάποιο πλεονέκτημα που έχει η Java.

Πόσο εύκολα μπορεί κάποιος να ανοίξει δική του εταιρεία Java development;

Έχω δει αρκετές εταιρείες spin off τελευταία οι οποίες κάνουν ανάπτυξη σε Java.

Ουσιαστικά το μόνο κόστος είναι αυτό της αγοράς των μηχανημάτων.

---

Powered by openSuSE 11 64-bit Edition

Μάλλον το έμπλεξες με το open source. Και .NET μπορείς να αναπτύξεις με open source εργαλεία, ή χρησιμοποιώντας τις εκδόσεις Express του Visual Studio.

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

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos