mboost-dp1
JSF / Java EE - Hvorfor
Windcape (49) skrev:Dvs. argumentet for valg af teknolgi, er fordi at udviklerne ikke kan finde ud af deres arbejde, og/eller ikke vil lære noget nyt.
Nej. Argumentet er, at HTML er ikke bedre end vores custom tags, ud fra at HTML er lettere at lære.
Windcape (49) skrev:Frontend skal bare være præsentation.
Der er mange lag. Hvor man skærer mellem frontend og backend er ikke noget du bestemmer.
Windcape (49) skrev:Hele konceptet er jo netop at du skal kunne skifte fra HTML til XML bare ved at ændre dit view. Hvis du benytter custom tags der generere HTML, så kan du ikke lave dit view om, uden at skulle lave nye custom tags!
Det er da også ufatteligt meget lettere at ændre et par hundrede custom tags, end tusindvis af views.
Og når ændringen så skal testes, er forskellen endnu større.
Tilføjelse til #47
Hvis jeg så f.eks. også skal tilbyde en RESTfull list af mine produkter:
Views:
ViewProducts.html
ViewProducts.xml
Og bling! problem solved.
Og hvis du skal bruge begge dele samtidig? Definere endnu flere tags? Definere overloads? Compilere endnu flere tags?
Ny view engine , ny javascript support... ind og lave flere custom tags der gør dit view endnu mere tight-coupled med sin business-logic istedet for at være stand alone?
Det er at genopfinde hjulet. Der er intet problem i at benytte en allerede velkendt teknologi som HTML. Plus du er 110% sikker som udvikler på hvilket HTML output du vil få.
Hvordan kan jeg vide hvad dine custom tags genererer uden at læse op på dem?
Hvis jeg så f.eks. også skal tilbyde en RESTfull list af mine produkter:
Views:
ViewProducts.html
ViewProducts.xml
Og bling! problem solved.
myplacedk (51) skrev:Det er da også ufatteligt meget lettere at ændre et par hundrede custom tags, end tusindvis af views.
Og hvis du skal bruge begge dele samtidig? Definere endnu flere tags? Definere overloads? Compilere endnu flere tags?
Ny view engine , ny javascript support... ind og lave flere custom tags der gør dit view endnu mere tight-coupled med sin business-logic istedet for at være stand alone?
Det er at genopfinde hjulet. Der er intet problem i at benytte en allerede velkendt teknologi som HTML. Plus du er 110% sikker som udvikler på hvilket HTML output du vil få.
Hvordan kan jeg vide hvad dine custom tags genererer uden at læse op på dem?
http://www.hanselman.com/blog/ASPNETMVCWebFormsUnp...
In a recent MVC design meeting someone said something like "we'll need a Repeater control" and a powerful and very technical boss-type said:
"We've got a repeater control, it's called a foreach loop."
Zing! That's so cool. Get out of my way and let me make some angle-brackets. Again, not for everyone, but for enough people that matters. Open Source projects like MVCContrib and hopefully a bunch of 3rd party component vendor types will drink in that simplicity and the power of statements like that and create helper methods and controls that we want, need and can use, and not just <mvc:TooBigDataGrid/>.
Windcape (52) skrev:Og hvis du skal bruge begge dele samtidig?
Jeg kan ikke kommentere på hvordan jeg vil løse et problem jeg ikke kender.
Windcape (52) skrev:Der er intet problem i at benytte en allerede velkendt teknologi som HTML.
Jo der er så, jeg har nævnt adskillige. I øvrigt kan HTML alene slet ikke løse opgaven.
Windcape (52) skrev:Plus du er 110% sikker som udvikler på hvilket HTML output du vil få.
Ja, det helvede har jeg været igennem.
Hvis de benytter mine custom tags ved jeg 100% sikkert hvad der bliver genereret. Magten er overført til den afdeling, som går op i det.
Windcape (52) skrev:Hvordan kan jeg vide hvad dine custom tags genererer uden at læse op på dem?
Det skal du ikke vide. Det er jo hele pointen med encapsulation. Jeg kan ændre deres output totalt uden at det vedrører dig.
Udviklerne skriver blot i JSP'en hvad de vil opnå. Så gør systemet et eller andet for at generere noget HTML (osv) som virker. Simpelt for dem, simpelt for mig.
De grundlæggende systemmoduler fra 32/70 platformen, er skrevet i PL/1.
De skriver stadigvæk batch i COBOL.
Hmmm troede faktisk kun det var ATP der benyttede PL1, men er langt fra sikker på, hvad de grundlæggende systemmoduler som du nævner er? er det deres onlinesystem (CICS)?
3270 er vel bare emulering af den terminal der blev brugt før PC'en dukkede op?
[bump]
Det er lige før, at man får lyst til at arbejde lidt med web igen. JSF lyder mere interessant end jeg husker. Især konceptet om at abstrahere lidt fra html'en er interessant. (Nej, ASP.NET abstraherer ikke fra html'en. Den gør os alle sammen skitzofræne i stedet.) Mange web-projekteters største problem, er i følge min erfaring "vedligehold", hvilket det lyder som om af JSF kan afhjælpe lidt.
Det er lige før, at man får lyst til at arbejde lidt med web igen. JSF lyder mere interessant end jeg husker. Især konceptet om at abstrahere lidt fra html'en er interessant. (Nej, ASP.NET abstraherer ikke fra html'en. Den gør os alle sammen skitzofræne i stedet.) Mange web-projekteters største problem, er i følge min erfaring "vedligehold", hvilket det lyder som om af JSF kan afhjælpe lidt.
Ja, hvis du vil spilde din tid på unødvendig kode, istedet for at arbejde med hvad der rent faktisk er relevant :)
Og at abstrahere væk fra HTML er negativt i min mening. ASP.NET's tilgang er at folk kan finde ud af HTML.
SUNs er at alle udviklerer er idioter der ikke kan forstå html, og derfor ikke skal arbejde med det selv.
Så må man jo vælge :)
Og at abstrahere væk fra HTML er negativt i min mening. ASP.NET's tilgang er at folk kan finde ud af HTML.
SUNs er at alle udviklerer er idioter der ikke kan forstå html, og derfor ikke skal arbejde med det selv.
Så må man jo vælge :)
Windcape (60) skrev:SUNs er at alle udviklerer er idioter der ikke kan forstå html, og derfor ikke skal arbejde med det selv.
Jeg tror nu nærmere at SUNs tilgangsvinkel er at putte fokus på "Seperation of Concerns", så folk der vil skrive backend kode kan gøre det, og folk der vil skrive frontend kode (HTML) kan gøre det.
Altså, lade udviklere koncentrere sig om sin spidskompetence.
#61
Både JSP og ASP.NET har MVC understøttelse. Dvs. at Views rent faktisk ER sepereret. Og hele konceptet med WebForms i ASP.NET var at man kunne give det over til designerne.
Og det havde bedre visual IDE understøttelse får 5 år siden, end JSP nogen sinde vil have :)
Men erfaringen viser jo netop at udviklerne *gerne* vil have kontrol over deres HTML. Selv med custom tags, så bliver en udvikler utolmodig, og ender med at skrive et hack uden om det.
Og så kunne det hele jo ligeså godt være lige meget.
Derudover mener jeg slet ikke at HTML har særlig meget med presentation at gøre, udover semantik. Selve layoutet laver du med CSS.
Både JSP og ASP.NET har MVC understøttelse. Dvs. at Views rent faktisk ER sepereret. Og hele konceptet med WebForms i ASP.NET var at man kunne give det over til designerne.
Og det havde bedre visual IDE understøttelse får 5 år siden, end JSP nogen sinde vil have :)
Men erfaringen viser jo netop at udviklerne *gerne* vil have kontrol over deres HTML. Selv med custom tags, så bliver en udvikler utolmodig, og ender med at skrive et hack uden om det.
Og så kunne det hele jo ligeså godt være lige meget.
Derudover mener jeg slet ikke at HTML har særlig meget med presentation at gøre, udover semantik. Selve layoutet laver du med CSS.
Windcape (60) skrev:SUNs er at alle udviklerer er idioter der ikke kan forstå html, og derfor ikke skal arbejde med det selv.
I Java EE antages det ofte at det er forskellige personer som:
- laver layoutet
- laver funktionaliteten
- laver flowet i applicationen
- deployer
- drifter
Funktionalitet og layout er ikke helt skarpt adskilt i JSF med JSP men JSP med facelets er tæt på.
Ja, men jeg synes det er ret underligt at definere flowet som noget seperat.arne_v (63) skrev:I Java EE antages det ofte at det er forskellige personer som:
- laver layoutet
- laver funktionaliteten
- laver flowet i applicationen
- deployer
- drifter
Funktionalitet og layout er ikke helt skarpt adskilt i JSF med JSP men JSP med facelets er tæt på.
Java er jo guds barn når det kommer til at kode efter navngivnings standarder, og ikke sprog-specifikke ting (ja, jeg synes Bean modellen er idioti på et højt niveau).
Så hvorfor er der ikke automatisk flow mapping til metoder ud fra en navngivnings standard?
/Users/Windcape/Edit
Burde helt åbenlyst mappe til
UserController.editUser("Windcape")
At uddelegere denne den af softwaren til andre personer er at overkomplikere tingene, gøre dem dyrere, og sværere at udvikling og maintaine.
Fordi hvor tit har du brug for at ændre på flowet i din application, uden også at ændre på funktionaliteten?
Men hvis det er målet at undgå HTML programming fuldstændig, hvorfor så ikke lave et custom layout-system ala. JavaFX eller Django (Python). Og Rails har vist også noget lign.arne_v (64) skrev:Det er muligt at det var en målsætning, men det har de ikke opnået. En web form side er ikke særligt HTML kompatibel.
De har jo netop bygget det på XML, og så pludselig besluttet sig for at brugeren måske slet ikke kan finde ud af XML.
Derudover kommer problemet jo med at custom-tag teknologien slet ikke er bygget til at arbejde med javascript libraries som JQuery.
Så lige pludselig har du en teknologi som kræver en sindsyg masse abstraction og encaptulation, hvor du bruger mere tid på at skrive ting som alligevel ikke bliver genbrugt, end at udvikle hvad der rent faktisk er vigtigt.
Men okay, det ligger også lidt til java som teknologi at foretrækker langsomme udviklingsmetoder ;)
Det ville vel være synd at sige at rapid-prototyping er særlig populært i java.
Tjaehh, du kan jo tage diskussionen med Gartner:
http://mediaproducts.gartner.com/reprints/oracle/a...
IBM's portal-løsning er Java, Microsofts (der vel at mærke ligger ret flot, synes jeg), er naturligvis .NET.
Oracle's portal er java - uden at være helt skarp på SAP, så _tror_ jeg måske også det er java der ligger bag - SUN er naturligvis java og Vigentte er også java.
Det er vist dem der ligger i leaders-kvadranten.
Det kan godt være du mener java, som portal-løsning er uddateret, men med Gartner i den ene hånd, og Windcapes holdninger i den anden hånd...hvem tror du de store forretninger der har brug for en større webbaseret løsning lytter til? :)
http://mediaproducts.gartner.com/reprints/oracle/a...
IBM's portal-løsning er Java, Microsofts (der vel at mærke ligger ret flot, synes jeg), er naturligvis .NET.
Oracle's portal er java - uden at være helt skarp på SAP, så _tror_ jeg måske også det er java der ligger bag - SUN er naturligvis java og Vigentte er også java.
Det er vist dem der ligger i leaders-kvadranten.
Det kan godt være du mener java, som portal-løsning er uddateret, men med Gartner i den ene hånd, og Windcapes holdninger i den anden hånd...hvem tror du de store forretninger der har brug for en større webbaseret løsning lytter til? :)
#68
Men siden hvornår har ERP løsninger handlet om hvad udviklerne mener er best, og ikke hvem der kan imponerer chefen mest?
IBM har jo imponeret både Danske Bank og den Danske Stat, ret meget. Men ikke leveret varen.
Cheferne er såmend ligeglade med og vi skal udviklere viderer i en elendig oldtids teknologi, bare det leverer varen.
Problemet ligger med Java som teknologi har udviklet sig for langsom, og alt viderudbygning i dag består af millioner af xml configurationer, og dertil hackede scriptsprog til at håndterer resten.
Java er jo på ingen måde et optimalt sprog til web på noget som helst plan, samt hele event og bean-modellen er håbløst uddateret.
Og typisk er problemet vel at folk vælger java fordi det er "stort og kendet", og aldrig undersøger andre teknologier. Fordi det lader til at være ret minimalt med java udviklerer som også har arbejdet, eller bare kender det mindste til, andre teknologier.
Rent sprogmæssigt kan jeg ikke se mig selv lave nyudvikling i Java hvis jeg kan undgå det. Der er ikke noget Java kan som C# ikke kan, men massere som C# kan som ikke kan lade sig gøre i java (overhovedet!).
Men siden hvornår har ERP løsninger handlet om hvad udviklerne mener er best, og ikke hvem der kan imponerer chefen mest?
IBM har jo imponeret både Danske Bank og den Danske Stat, ret meget. Men ikke leveret varen.
Cheferne er såmend ligeglade med og vi skal udviklere viderer i en elendig oldtids teknologi, bare det leverer varen.
Problemet ligger med Java som teknologi har udviklet sig for langsom, og alt viderudbygning i dag består af millioner af xml configurationer, og dertil hackede scriptsprog til at håndterer resten.
Java er jo på ingen måde et optimalt sprog til web på noget som helst plan, samt hele event og bean-modellen er håbløst uddateret.
Og typisk er problemet vel at folk vælger java fordi det er "stort og kendet", og aldrig undersøger andre teknologier. Fordi det lader til at være ret minimalt med java udviklerer som også har arbejdet, eller bare kender det mindste til, andre teknologier.
Rent sprogmæssigt kan jeg ikke se mig selv lave nyudvikling i Java hvis jeg kan undgå det. Der er ikke noget Java kan som C# ikke kan, men massere som C# kan som ikke kan lade sig gøre i java (overhovedet!).
#70
...synes du. ;-)
Java er ikke perfekt. Men det er der intet der er, og jeg kan bedre lide Java end C#/.net.
For eksempel fordi Java's platformsuafhængighed kan bruges til noget i praksis.
Sådan er folk så forskellige, vi prioriterer de forskellige egenskaber forskelligt.
...synes du. ;-)
Java er ikke perfekt. Men det er der intet der er, og jeg kan bedre lide Java end C#/.net.
For eksempel fordi Java's platformsuafhængighed kan bruges til noget i praksis.
Sådan er folk så forskellige, vi prioriterer de forskellige egenskaber forskelligt.
Til webudvikling betyder det jo absolut intet.myplacedk (71) skrev:For eksempel fordi Java's platformsuafhængighed kan bruges til noget i praksis.
Jeg tror ikke på at de forskellige application servere bruger samme bytecode til både Windows, Linux og Solaris. Så når du alligevel skal bruge en speciel server til din kode, så kan du jo også godt kører C#/Mono.
Og til applikations programmering så synes jeg det er noget fis at blive ved med at sige at Mono ikke kan bruges, hvis man aldrig har arbejdet med det.
Derudover så er forskellen på Java og C# som sprog ikke meninger, det er facts. Og hvis man så ikke vil se ordenlig generics, delegates, linq, og ordenlig event handling som fordele, så må man godt nok selv om det.
Hvorfor ikke skrive det hele i COBOL i stedet, hvis sproget betyder så lidt? ;) Eller ASM?
(Og, ja, jeg synes det er et problem at et route-mapping tager 30 linjers xml i java, mod 4 linjers C#.)
Windcape (72) skrev:Jeg tror ikke på at de forskellige application servere bruger samme bytecode til både Windows, Linux og Solaris.
Og det er jo så forkert. Det er faktisk helt standard at deploye samme ear/war/ejb jar on different OS's.
Fordi Java er meget seriøs omkring compatibility.
Både Java SE og EE har test kits, hvor implementationer skal bestå 100% førend de kan kalde sig henholdsvis Java SE og EE.
Windcape (72) skrev:Og til applikations programmering så synes jeg det er noget fis at blive ved med at sige at Mono ikke kan bruges, hvis man aldrig har arbejdet med det.
Man kan jo slå op på Mono's egne sider og se hvad de mangler i forhold til MS .NET.
95% eller 99% kompabilitet er ikke kompabilitet.
Og iøvrigt så findes Mono ikke til nær alle de platforme som Java findes til.
Windcape (72) skrev:Til webudvikling betyder det jo absolut intet.
Jeg benytter mig nu ellers af det til dagligt. (Jeg koder og udfører første test under et radikalt anderledes OS, end de bliver brugt i produktion.)
Windcape (72) skrev:Og til applikations programmering så synes jeg det er noget fis at blive ved med at sige at Mono ikke kan bruges, hvis man aldrig har arbejdet med det.
Jeg har flere gange prøvet at køre mono-programmer i Linux. Det har KUN fungeret, når de selv har reklameret med at programmet er designet til det. Det kan jeg ikke bruge til noget.
Jeg har mange gange kørt Java-software i Linux, som kun er designet til Windows. Jeg har kun to betingelser: Lad være med at lade en Windows-installer være mit eneste valg, og kod bare en lille smule fornuftigt. (Dvs. lad være med at hardcode stier som "C:\Program Files", hvilket jo også ville være dumt alligevel.)
Windcape (72) skrev:Derudover så er forskellen på Java og C# som sprog ikke meninger, det er facts.
Alt har fordele og ulemper. Hvad der er bedst kommer an på hvordan man vægter dem. Og DET er subjektivt.
Windcape (72) skrev:(Og, ja, jeg synes det er et problem at et route-mapping tager 30 linjers xml i java, mod 4 linjers C#.)
Vi bruger så faktisk præcist 4 linjers xml pr. mapping. Den første er et start-tag uden attributter, og den sidste er det tilsvarende slut-tag. (Plus en ekstra linje pr. ekstra "udgang". Men de er meget korte, så du kan jo bare fjerne linjeskiftet hvis du har lyst.)
Jeg mente selve serverne. Altså Tomcat, Glassfish, JBoss, Websphere, ikke hvad du deployer på dem.arne_v (73) skrev:Og det er jo så forkert. Det er faktisk helt standard at deploye samme ear/war/ejb jar on different OS's.
Du kan også køre en ASP.NET application fra Linux, hvis du laver en oversætter.
Hvis vi nu definere alle former for Unix som én platform, så er forskellen vel ikke så stor længere.arne_v (74) skrev:Og iøvrigt så findes Mono ikke til nær alle de platforme som Java findes til.
Jeg har udvikling hobby software (som endda benyttede DirectX), som en ven så har kørt og arbejdet videre på under Mono. Det er jo et spørgsmål om udviklerne koder til det, det er præcist de samme problemer som Java har.myplacedk (75) skrev:Jeg har flere gange prøvet at køre mono-programmer i Linux. Det har KUN fungeret, når de selv har reklameret med at programmet er designet til det. Det kan jeg ikke bruge til noget.
Jeg har mange gange kørt Java-software i Linux, som kun er designet til Windows. Jeg har kun to betingelser: Lad være med at lade en Windows-installer være mit eneste valg, og kod bare en lille smule fornuftigt. (Dvs. lad være med at hardcode stier som "C:\Program Files", hvilket jo også ville være dumt alligevel.)
Men modsat Java, så kan udviklerne af Mono have tilføjelser til sproget/platformen. Lad os lige se hvor meget der kunne ske hvis lave blev fuld open source. Så ville vi måske ikke skulle vente i 10 år på at bean-modellen bliver skiftet ud med noget mere fornuftigt (som rigtige properties).
Dvs. som udvikler ville du heller aldrig kunne finde på at vælge java, men som en chef der har læst en masse fine rapporter, og snakket med en masse forrretningsfolk som skal sælge deres produkt, ville du godt? ;-)myplacedk (75) skrev:Alt har fordele og ulemper. Hvad der er bedst kommer an på hvordan man vægter dem. Og DET er subjektivt.
Så er det jo godt der er andre end SUN der laver MVC frameworks, da SUN tydeligvis ikke kan finde ud af det (JSF).myplacedk (75) skrev:Vi bruger så faktisk præcist 4 linjers xml pr. mapping. Den første er et start-tag uden attributter, og den sidste er det tilsvarende slut-tag. (Plus en ekstra linje pr. ekstra "udgang". Men de er meget korte, så du kan jo bare fjerne linjeskiftet hvis du har lyst.)
Windcape (76) skrev:Dvs. som udvikler ville du heller aldrig kunne finde på at vælge java,
Du virker mere og mere som om det er din holdning der er den korrekte, og ikke at du ønsker at blive klogere.
Jeg har jo sagt til dig adskillige gange at jeg foretrækker Java frem for C#.
Skulle jeg støde på en opgave hvor jeg synes C# er mere passende, vil jeg undgå opgaven.
Windcape (76) skrev:en chef der har læst en masse fine rapporter, og snakket med en masse forrretningsfolk som skal sælge deres produkt, ville du godt? ;-)
Er du bitter på en arbejdsgiver, eller sådan noget? Jeg er vant til at ledelsen/chefen stoler mere på sine egne eksperter, end smarte sælgere.
Windcape (76) skrev:Så er det jo godt der er andre end SUN der laver MVC frameworks, da SUN tydeligvis ikke kan finde ud af det (JSF).
Dig: Java dårligt fordi den bruger 30 linjer på noget jeg kan på 4.
Mig: Jeg gør det på 4 i Java.
Dig: Jeg kan stadig sige noget negativt, i stedet for at blive klogere.
Windcape (76) skrev:Jeg mente selve serverne. Altså Tomcat, Glassfish, JBoss, Websphere, ikke hvad du deployer på dem.
Nu er de fleste Java udviklere nok mere interesseret i deres apps end i app serveren.
Men anyway.
Hvorfor prøver du ikke tingene inden du udtaler dig?
Servere som Tomcat og JBoss kører fint fra samme ZIP på både Windows og Linux.
De er ren Java.
Der er en startup.bat/startup.sh og en run.bat/run.sh respektive.
WebSphere er også ren Java i nyere versioner, men den kommer med en OS specifik installer og den Java version som den er certificeret til.
Windcape (76) skrev:Du kan også køre en ASP.NET application fra Linux, hvis du laver en oversætter.
Der er ingen oversættelse.
Java EE er en standard. De forskellige leverandører laver implementationer som følger standarden.
Og de bliver testet inden de får deres godkendelse.
Windcape (76) skrev:Hvis vi nu definere alle former for Unix som én platform, så er forskellen vel ikke så stor længere.
Næh. Den er nærmest større.
Ganske vist mangler AIX og HP-UX som supporterede platforme.
Men Windows er den eneste ikke *nix platform der er supporteret.
z/OS, i og OpenVMS - ingen Mono.
Windcape (76) skrev:Jeg har udvikling hobby software (som endda benyttede DirectX), som en ven så har kørt og arbejdet videre på under Mono. Det er jo et spørgsmål om udviklerne koder til det, det er præcist de samme problemer som Java har.
Nej.
Mono kigger på MS .NET og implementerer tingene så godt de kan og dokumenterer det der ikke virker.
For Java er der en specifikation og en skrap test. Hvis ikke implementationen betsår testen så er det ikke Java.
Det kostede MS 20 millioner dollars da de lavede en ikke compliant implementation.
Windcape (76) skrev:Men modsat Java, så kan udviklerne af Mono have tilføjelser til sproget/platformen. Lad os lige se hvor meget der kunne ske hvis lave blev fuld open source.
Java er en specifikation.
Og der er open source implementationer.
Flere endda.
Undersøg tingene.
Windcape (76) skrev:
Så ville vi måske ikke skulle vente i 10 år på at bean-modellen bliver skiftet ud med noget mere fornuftigt (som rigtige properties).
Der eksisterer ikke noget der hedder rigtige properties.
.NET har valgt at have to forskellige syntaxer for metode kald.
Men det fungerer helt ens i .NET og Java.
Windcape (76) skrev:Så er det jo godt der er andre end SUN der laver MVC frameworks, da SUN tydeligvis ikke kan finde ud af det (JSF).
JSF er ikke lavet af SUN men af JCP.
Expert group for 1.0 og 1.1 (JSR 127) havde medlemmer fra: SUN, IBM, Oracle, BEA, Borland, Novell, Macromedia, HP, Fujitsu, EMC, EDS etc..
1.2 (JSR 252) havde fra SUN, Oracle, TriFork, Redhat, CA etc..
Syntaks er også det vigtigste i et programmerings sprog, da det nu engang er det vi bruger mest tid på!arne_v (81) skrev:.NET har valgt at have to forskellige syntaxer for metode kald.
Det er .NET ogsåarne_v (81) skrev:Java er en specifikation.
Og der er open source implementationer.
Flere endda.
Undersøg tingene.
http://en.wikipedia.org/wiki/Shared_Source_Common_...
Forskellen er at Mono ikke bliver sagsøgt for 20 millioner når de laver nye ting til C# og deres libraries.
http://www.ondotnet.com/pub/a/dotnet/2005/10/31/in...
Osborn: I want to come back to LINQ, but going back to the relative positioning of languages, again, one of the things that [Microsoft Visual Studio .NET product manager] Tony Goodhew said in that interview was that Microsoft studies were showing that people tended to use two or more languages to do their programming. And there was a sense at the time that [languages were just] syntactic sugar. You choose the language that you're most comfortable with.
Do you think that's changed? We don't say that anymore.
Hejlsberg: Well, we don't, but it's all syntax in the end, right? I mean otherwise, we'd just be handing over an XML document that describes the abstract syntax tree of what you want done, and that could be the syntax, too, but it's obviously not usable by programmers. So I think programming languages occupy a special position in people's minds in the sense that just as your spoken language is the way you express yourself, so is [your] programming language; it's how you express yourself.
And the syntax is the manifestation of the programming language, and it actually, in many ways affects how you think about your program and so forth. So syntax does matter, and it matters a lot, I think.
Osborn: I want to come back to LINQ, but going back to the relative positioning of languages, again, one of the things that [Microsoft Visual Studio .NET product manager] Tony Goodhew said in that interview was that Microsoft studies were showing that people tended to use two or more languages to do their programming. And there was a sense at the time that [languages were just] syntactic sugar. You choose the language that you're most comfortable with.
Do you think that's changed? We don't say that anymore.
Hejlsberg: Well, we don't, but it's all syntax in the end, right? I mean otherwise, we'd just be handing over an XML document that describes the abstract syntax tree of what you want done, and that could be the syntax, too, but it's obviously not usable by programmers. So I think programming languages occupy a special position in people's minds in the sense that just as your spoken language is the way you express yourself, so is [your] programming language; it's how you express yourself.
And the syntax is the manifestation of the programming language, and it actually, in many ways affects how you think about your program and so forth. So syntax does matter, and it matters a lot, I think.
Derudover er der jo problemer med bean-modellen. F.eks. JSF kræver at du har både Getters og Setters for at kunne benyttes.
Så får at lave en read-only property skal man definere en blank setter.
Jeg synes det er idioti på et højt plan, og at det ikke er blevet fixet over en periode på 10 år viser jo bare hvor uddateret Java er som sprog.
Det er vel kun heldigt for java udviklerne at C# er låst til een platform ;)
Så får at lave en read-only property skal man definere en blank setter.
public void setFoo() {
// part of read-only property, waste of code, hurrayz!
}Jeg synes det er idioti på et højt plan, og at det ikke er blevet fixet over en periode på 10 år viser jo bare hvor uddateret Java er som sprog.
Det er vel kun heldigt for java udviklerne at C# er låst til een platform ;)
Windcape (83) skrev:Forskellen er at Mono ikke bliver sagsøgt for 20 millioner når de laver nye ting til C# og deres libraries.
Og det er så en af de store grunde til at jeg foretrækker Java.
Det behøver du slet ikke at være enig i, men jeg håber at du forstår det.
Selvfølgelig mener jeg ikke selve det faktum at folk bliver sagsøgt, men at Java er Java uanset platform. Det virker bare. Og hvis nogen prøver at ødelægge det, får de tæsk.
Det er for at undgå netop den situation jeg beskrev tidligere, at jeg har været i rigeligt mange gange: At C#-programmer stadig kun virker på de platforme, de er designet til at virke på.
Koder du så også stadigvæk i Java 1.4 uden generics? :-)
Mono's specielle udvidelser er extension methods, hvilket er et bibliotek (assembly) du også kan importere i MS.NET.
Forskellen er bare at extension methods virker som en del af sproget, istedet for et statisk bibliotek. Endnu en fordel til udvidelsen af C#.
Jeg tror slet ikke jeg kunne leve uden .Where / .Select / .OfType / .Single i noget programmerings sprog nu.
Mono's specielle udvidelser er extension methods, hvilket er et bibliotek (assembly) du også kan importere i MS.NET.
Forskellen er bare at extension methods virker som en del af sproget, istedet for et statisk bibliotek. Endnu en fordel til udvidelsen af C#.
Jeg tror slet ikke jeg kunne leve uden .Where / .Select / .OfType / .Single i noget programmerings sprog nu.
Windcape (87) skrev:Koder du så også stadigvæk i Java 1.4 uden generics? :-)
Det sker, men jeg kan ikke lige se hvad det har med sagen at gøre. (Vi har for den sags skyld vist også noget Java 1.3 et eller andet sted, men nu kommer det hele snart op på mindst 1.5.)
Windcape (87) skrev:Mono's specielle udvidelser er extension methods, hvilket er et bibliotek (assembly) du også kan importere i MS.NET.
Jeg kender ikke noget til hvorfor det virker som det gør (og jeg forstår ikke meget af hvad du siger her), jeg kan bare se at det ikke virker lige så godt som Java.
Windcape (87) skrev:Jeg tror slet ikke jeg kunne leve uden .Where / .Select / .OfType / .Single i noget programmerings sprog nu.
Det må være surt at være så svagelig. ;-)
Jeg nyder da enhver forbedring i moderne teknologi, men jeg overlever fint at arbejde med noget voksent.
"Forældet" , ikke voksent :)myplacedk (88) skrev:men jeg overlever fint at arbejde med noget voksent.
Men du nyder vel også at skulle importerer dit bibliotek af statiske hjælpe metoder du har lavet de sidste mange år, fordi at sproget du arbejder med ikke bliver opdateret med noget moderne.
Verden står ikke stille bare fordi at Java gør :)
#89 Jeg tror efterhånden at vi har fattet at du ikke er glad for java :)
Jeg står til at skulle bruge de næste 60 år af mit liv som udvikler. Jeg synes nok det er relevant at have meninger om valg af teknologi.paradise_lost (90) skrev:#89 Jeg tror efterhånden at vi har fattet at du ikke er glad for java :)
Problemet er jo når folk vælger teknologi uden noget reelt teknisk grundlag. At basere alle valg ud fra et organisationisk synspunkt, eller fra et økonomisk synspunkt er ikke godt.
Dette er en forum for nørder, og det er skræmmende hvor få som har indsigt nok til at ville snakke om dette.
Og ja, hvordan kan nogen være glad for et sprog hvor du ikke engang kan overloade metoder på det's grundlæggende type, java.lang.Object.
Det begrænser jo enhver form for API udvikling der ville gøre det til et bedre sprog.
Windcape (89) skrev:"Forældet" , ikke voksent :)
Voksent. Jeg valgte det ord med meget omhu. Jeg tror altså ikke at verden flytter sig så hurtigt som du tror den gør.
Windcape (89) skrev:Men du nyder vel også at skulle importerer dit bibliotek af statiske hjælpe metoder du har lavet de sidste mange år, fordi at sproget du arbejder med ikke bliver opdateret med noget moderne.
Blah-blah.
Windcape (89) skrev:Verden står ikke stille bare fordi at Java gør :)
Java står ikke stille.
Windcape (91) skrev:Og ja, hvordan kan nogen være glad for et sprog hvor du ikke engang kan overloade metoder på det's grundlæggende type, java.lang.Object.
Hm.
C# og VB.NET er vist de eneste mainstream sprog med extension methods og dermed i stand til at overloade metoder på et vilkårligt objekt.
Der er faktisk folk som er glade for andre sprog end disse.
Og derudover tror jeg ikke at der er ret mange som laver extension methods til System.Object som overloader metoder. Hvad skulle det være. En ToString som tager et argument som gør et eller andet?
Jeg tænkte mere på følgende:arne_v (95) skrev:C# og VB.NET er vist de eneste mainstream sprog med extension methods og dermed i stand til at overloade metoder på et vilkårligt objekt.
class Test<T>
{
public bool equals(T obj)
{
// bla
}
public bool equals(Object obj)
{
// bla
}
}
Jeg stødte ind i problemet, da jeg forsøgte at implementere C#'s interface til formålet i Java.
Det overraskende mig, samt nogle andre folk, en hel del at Java ikke understøttede det.
Windcape (91) skrev:Jeg står til at skulle bruge de næste 60 år af mit liv som udvikler. Jeg synes nok det er relevant at have meninger om valg af teknologi.
Hvis ikke snart du begynder at lære noget af at snakke med andre udviklere, er dine meninger intet værd.
Windcape (91) skrev:Og ja, hvordan kan nogen være glad for et sprog hvor du ikke engang kan overloade metoder på det's grundlæggende type, java.lang.Object.
(Efter at have fundet ud af hvad du mener.)
Ih hvor forfærdeligt. Så skal man bruge en smule anderledes syntax for at opnår præcist det samme. Det ville da også få mig til at udelukke et major sprog og utallige karriere-muligheder. Hvis jeg var dig. :-/
Windcape (91) skrev:Det begrænser jo enhver form for API udvikling der ville gøre det til et bedre sprog.
Ja, jeg tror også det er en af de større grunde til at Java aldrig blev populært i andet end akademiske kredse, og direktører som træffer beslutninger ud fra hvad smarte sælgere siger uden at lytte til sine egne eksperter. *suk*
Gå til top
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Programmering
Gå til bund