mboost-dp1
SXC - clix
Som jeg hørte en gut fra Borland sige en gang "We were about to take over the entire market for celcius to farenheit converters" om noget "visuel programmering" de havde gang i hvor de prøvede at rykke sproget op på et meget højt niveau. Pointen er at mange forsøg på at lave super højniveau sprog ender med at man ikke kan abstrahere sig fra alle de små detaljer som i sidste ende er nødvendige hvorefter helloworld og celcius->farenheit convertere bliver noget af det mest avancerede man kan lave uden at man støder på begrænsninger der gør super-højniveau sproget ubrugeligt. Jeg siger ikke at Ola Bini nødvendigvis tager fejl, men at vi stadig mangler at se eksempler på et praktisk anvendeligt sprog der lever op til hans ønsker.
Asger.F (2) skrev:Det er da hans egen skyld hvis han bruger det forkerte programmeringssprog til opgaven. Hvis han ikke synes der findes noget godt sprog til opgaven, så kan han da ikke sige de andre er "dårlige," da det er et relativt begreb.
Hans pointe er jo netop at der er langt mellem de gode sprog, hvilket han har helt ret i imo.
Det er lidt vildt at høre en ekspert udtale sig om Java som et lavniveausprog.
Java er jo et 3.generations sprog, lige som næsten alle andre programmeringssprog, og det har jo altid været drømmen at udvikle 4. og 5. generationssprog.
Det er jo ikke noget som Ola er den første til at sige. Det har jo altid været ønsket at man en dag bare kunne tale til sin computer og sige "lav et program som løser bla bla".. og så skete resten af sig selv.
Sjovt nok har historien vist at hver gang man "ryger højere op i generation" ender man med et sprog som ikke kan løse alle opgaver lige godt... eller måske endda er meget begrænset til netop en opgave. (F.eks. SQL som anses som 4.generation.)
Så, jeg har svært ved at se hvad Ola får ud af at gentage en kritik som er blevet gentaget i over 50år.... det havde været lidt mere spændende hvis han selv havde svaret på dette problem.
Java er jo et 3.generations sprog, lige som næsten alle andre programmeringssprog, og det har jo altid været drømmen at udvikle 4. og 5. generationssprog.
Det er jo ikke noget som Ola er den første til at sige. Det har jo altid været ønsket at man en dag bare kunne tale til sin computer og sige "lav et program som løser bla bla".. og så skete resten af sig selv.
Sjovt nok har historien vist at hver gang man "ryger højere op i generation" ender man med et sprog som ikke kan løse alle opgaver lige godt... eller måske endda er meget begrænset til netop en opgave. (F.eks. SQL som anses som 4.generation.)
Så, jeg har svært ved at se hvad Ola får ud af at gentage en kritik som er blevet gentaget i over 50år.... det havde været lidt mere spændende hvis han selv havde svaret på dette problem.
Sikke en usaglig og ligegyldig kritik. Kravene for at "tilfredsstille" compileren er der for at indgå fejl i programmerne og mange af den slags fejl løses ret elegant af et typesystem som det i Java. At han selv er fra en anden skole som går ind for sprog uden statiske typer er sådan set bare hans subjektive holdning. At kalde Java et lav-niveau sprog fordi det bruger stærke og statiske typer er det rene sludder og vrøvl.
EDIT: Det kan godt være at han sagde noget andet oprindeligt. Den her historie har været igennem ComputerWorld-filtret.
EDIT: Det kan godt være at han sagde noget andet oprindeligt. Den her historie har været igennem ComputerWorld-filtret.
#8 Hehehe :)
#9 Måske :)
Jeg kan bedst lide at lege i lav/middels niveau sproget C/C++, fordi jeg har så meget kontrol, at hvis noget mangler kan jeg lave det selv :) (Plus et ocean af gode biblioteker) Føler mig også mere tryg at styre hukommelsen selv, fremfor en eller anden usynlig skraldemand rydder op efter mig 8|
Men kan godt se det fra et forretnings synspunkt - det er vel IO af data fra DB'er til GUI'er, og diverse generelle beregninger, så lidt crazy at skulle lave det på lavt/middel niveau :)
Jeg forstår dog ikke hvorfor et godt framework ikke kan løse hans problem. Kan ikke se hvorfor et sprog skal have nogen faciliteter andet end give muligheden for at skrive maskinkode igennem menneskesprog. (Og så måske lige et par nødvendige standard biblioteker så man kan skrive til sin konsol? Hehe)
#9 Måske :)
Jeg kan bedst lide at lege i lav/middels niveau sproget C/C++, fordi jeg har så meget kontrol, at hvis noget mangler kan jeg lave det selv :) (Plus et ocean af gode biblioteker) Føler mig også mere tryg at styre hukommelsen selv, fremfor en eller anden usynlig skraldemand rydder op efter mig 8|
Men kan godt se det fra et forretnings synspunkt - det er vel IO af data fra DB'er til GUI'er, og diverse generelle beregninger, så lidt crazy at skulle lave det på lavt/middel niveau :)
Jeg forstår dog ikke hvorfor et godt framework ikke kan løse hans problem. Kan ikke se hvorfor et sprog skal have nogen faciliteter andet end give muligheden for at skrive maskinkode igennem menneskesprog. (Og så måske lige et par nødvendige standard biblioteker så man kan skrive til sin konsol? Hehe)
jopsen (8) skrev:Så har man hørt det med :)
Ja den studsede jeg sgu også over!
Det er sgu for stupidt at sidde og sige at andre programmeringssprog er dårlige bare fordi man ikke forstår at bruge dem til de rigtige formål.
Jeg ville nødigt hverken sidde og programmere en hjemmeside i assembler, eller programmere microchips i Java eller Ruby.
Det var da godt nok det værste jeg har længe har læst. Både Java og C# mm. er da udemærkede eksempler på netop god kode-skik og samtidig undgå at tale for meget med compileren.
Ærlig talt ved manden overhovedet hvad ASM og C er.. Fordi så ville han da netop kunne se at der er sket et mindre kvante-spring siden da.
Ærlig talt ved manden overhovedet hvad ASM og C er.. Fordi så ville han da netop kunne se at der er sket et mindre kvante-spring siden da.
Har siddet og læst kommentarerne og det der falder mig for øje er, at folk forsvarer sprogene ud fra, at de hver især har deres styrker og man skal vælge sproget ud fra opgaven.
Dette mener jeg i sig selv er et problem. Selvfølgelig er vi mildvidt fra en verden med et sprog "to rule them all", som man kan programmere i efter et weekend kursus. Men jeg håber da det stille og roligt er den vej vi bevæger os..
Utopi? Ja det tror jeg faktisk :P
Dette mener jeg i sig selv er et problem. Selvfølgelig er vi mildvidt fra en verden med et sprog "to rule them all", som man kan programmere i efter et weekend kursus. Men jeg håber da det stille og roligt er den vej vi bevæger os..
Utopi? Ja det tror jeg faktisk :P
#13
Ja, det er utopi. Givet valget mellem et værktøj som kan alt, og et værktøj som er god til det jeg skal bruge det til, så vil jeg aldrig vælge et værktøj som kan alt.
Det jeg elsker i et sprog på ét tidspunkt, hader jeg på et andet tidspunkt. Det tror jeg aldrig vil ændre sig.
Ja, det er utopi. Givet valget mellem et værktøj som kan alt, og et værktøj som er god til det jeg skal bruge det til, så vil jeg aldrig vælge et værktøj som kan alt.
Det jeg elsker i et sprog på ét tidspunkt, hader jeg på et andet tidspunkt. Det tror jeg aldrig vil ændre sig.
Jeg kan godt se hans pointe.
Jeg er selv ret glad for C++ , fordi man har fuldstændig kontrol over hvad programmet gør. Det er et sprog som alle programmører burde kende, netop fordi den giver denne kontrol, og for at kunne bruge denne kontrol er man nødt til at kunne overskue hvordan det hele hænger sammen.
Men jeg er også ret glad for python, af samme grund som overfor. Man skal ikke bekymre sig så meget om små detaljer og obskur syntaks, og man kan i stedet koncentrere sig om programmets hovedformål.
Jeg er selv ret glad for C++ , fordi man har fuldstændig kontrol over hvad programmet gør. Det er et sprog som alle programmører burde kende, netop fordi den giver denne kontrol, og for at kunne bruge denne kontrol er man nødt til at kunne overskue hvordan det hele hænger sammen.
Men jeg er også ret glad for python, af samme grund som overfor. Man skal ikke bekymre sig så meget om små detaljer og obskur syntaks, og man kan i stedet koncentrere sig om programmets hovedformål.
myplacedk (14) skrev:#13
Ja, det er utopi. Givet valget mellem et værktøj som kan alt, og et værktøj som er god til det jeg skal bruge det til, så vil jeg aldrig vælge et værktøj som kan alt.
Det ku godt være du ramte sømmet på hovedet dér. Hvis vi tager en værktøjsanalogi, kunne man jo sige at vi siden stenalderen har bevæget os fra primitive flintesten til hammer, skruetrækker, sav, whatever. Men de ting har vi jo haft i årtusinder, så måske vi lidt har nået en grænse? Selvfølgelig er der også store fabriksapparater der "kan lidt mere", men de er jo netop også udviklet til en specifik opgave. Det han leder efter, er et enkelt værktøj der kan bygge huse, biler, tallerkener, ikea-møbler. Det ser jeg bare ikke lige ske. Men som det er nævnt før, kan man komme tæt på, ved at bygge store, flotte og brugervenlige frameworks.
Just my ¢2
Selvfølgelig kan det ske og det er sket.
Er ikke mere kompliceret end at moderne, gode, programmeringssprog kommer med en masse forud-skrevne objekter til gængse opgaver, mens man i f.eks. Java er nødt til at skrive næsten al sådan kode selv.
Sidder lige nu med en Java-app, hvor selv DataTable-objektet er hjemmeskrevet, suk! I mere moderne sprog er hele dataadgangen f.eks. lagt ud i medleverede objekter, hvad der unægteligt er en hel del lettere at gå til.
/M
Er ikke mere kompliceret end at moderne, gode, programmeringssprog kommer med en masse forud-skrevne objekter til gængse opgaver, mens man i f.eks. Java er nødt til at skrive næsten al sådan kode selv.
Sidder lige nu med en Java-app, hvor selv DataTable-objektet er hjemmeskrevet, suk! I mere moderne sprog er hele dataadgangen f.eks. lagt ud i medleverede objekter, hvad der unægteligt er en hel del lettere at gå til.
/M
#17
Jeg er enig i at Java API'et godt kunne trænge til noget mere "convenience". (Prøv at overføre indholdet fra en tekstfil til en String-variabel i Java og fx. PHP.)
Men når jeg koder i Java til daglig, har jeg altså ikke det problem. Jeg har tonsvis af "forud-skrevne objekter". Nogle som gør noget Java API'et måske burde gøre, nogle gør noget API'et egentlig godt kan men ikke helt på den måde vi ønsker, og en masse som opfylder et behov Sun aldrig kunne have forudset.
Det er kun noget man ser i små projekter, og ikke en absolut sandhed om Java.
Tag nu fx. metoden til at kopiere fra en tekst til en variabel. Sådan en metode ville jeg aldrig kalde selv. Jeg kalder en metode, som dels selv skal finde det nøjagtige filnavn, selv skal finde stien, tegnsæt skal håndteres, og indholdet skal typisk også fortolkes.
En convenience-metode til at læse en fil med én statement i stedet for 5 linjers kode ville da være cute nok, men i praksis ville det intet betyde for mig/vores system.
Jeg er enig i at Java API'et godt kunne trænge til noget mere "convenience". (Prøv at overføre indholdet fra en tekstfil til en String-variabel i Java og fx. PHP.)
Men når jeg koder i Java til daglig, har jeg altså ikke det problem. Jeg har tonsvis af "forud-skrevne objekter". Nogle som gør noget Java API'et måske burde gøre, nogle gør noget API'et egentlig godt kan men ikke helt på den måde vi ønsker, og en masse som opfylder et behov Sun aldrig kunne have forudset.
Det er kun noget man ser i små projekter, og ikke en absolut sandhed om Java.
Tag nu fx. metoden til at kopiere fra en tekst til en variabel. Sådan en metode ville jeg aldrig kalde selv. Jeg kalder en metode, som dels selv skal finde det nøjagtige filnavn, selv skal finde stien, tegnsæt skal håndteres, og indholdet skal typisk også fortolkes.
En convenience-metode til at læse en fil med én statement i stedet for 5 linjers kode ville da være cute nok, men i praksis ville det intet betyde for mig/vores system.
Forskellen er så at:myplacedk (18) skrev:#17
Tag nu fx. metoden til at kopiere fra en tekst til en variabel. Sådan en metode ville jeg aldrig kalde selv. Jeg kalder en metode, som dels selv skal finde det nøjagtige filnavn, selv skal finde stien, tegnsæt skal håndteres, og indholdet skal typisk også fortolkes.
En convenience-metode til at læse en fil med én statement i stedet for 5 linjers kode ville da være cute nok, men i praksis ville det intet betyde for mig/vores system.
- PHP tillader kun den simple version (convenience)
- Java tillader kun den besværlige metode
- C# tillader begge dele,
Derfor vil jeg personligt vælge det værktøj som giver mig begge muligheder.
Derudover snakkes der vel rent faktisk om selve sprogenen, og ikke deres API?
Til webudvikling har PHP på nuværende tidspunkt det mest omfattende API. Men er ikke særlig brugbart til så mange andre ting.
Hvor at Java/C# har nogle enorme APIs (JavaAPI/.NET) til andre formål, men hvor .NET klart er det hurtigest udviklende i disse år.
Til webudvikling har PHP på nuværende tidspunkt det mest omfattende API. Men er ikke særlig brugbart til så mange andre ting.
Hvor at Java/C# har nogle enorme APIs (JavaAPI/.NET) til andre formål, men hvor .NET klart er det hurtigest udviklende i disse år.
Fra et rent praktisk synspunkt, korrekt.myplacedk (23) skrev:Det betyder intet i et større projekt.
Men set ud fra et synspunkt hvor du skal vælge sproget (hvis du f.eks. ligesom mig er lige dygtig til begge dele), så er Java jo åbenlyst "dårligere" end C# pga. manglende features.
Hvilket vel netop er en del af Hr. Bini's pointe.
Man kan også skrive sine ting i inline assembler, det er altså bare ikke smart!
Windcape (24) skrev:Men set ud fra et synspunkt hvor du skal vælge sproget (hvis du f.eks. ligesom mig er lige dygtig til begge dele), så er Java jo åbenlyst "dårligere" end C# pga. manglende features.
Jeg synes nu der er langt vigtigere forskelle.
Windcape (24) skrev:Man kan også skrive sine ting i inline assembler, det er altså bare ikke smart!
Ja, men det vil jo tage en væsentlig mængde ressourcer, og forskellen kan derfor ikke sammenlignes.
Jeg kan tilføje, at i store projekter er der alligevel en tendens til at convenience-metoder (og klasser osv.) ikke benyttes (direkte), man laver i stedet sin egen udgave.
Hvis der ikke er nogle alternativer ja.myplacedk (25) skrev:Jeg kan tilføje, at i store projekter er der alligevel en tendens til at convenience-metoder (og klasser osv.) ikke benyttes (direkte), man laver i stedet sin egen udgave.
Jeg foretrækker meget at folk benytter hvad API'et tillader som standard fordi dette typisk er bedre dokumenteret og sandsyneligvis også er bedre testet.
Eksemple: En af mine medstuderende havde skrevet en IPAddress klasse i Java.... uden at havde undersøgt om der allerede var en i API'et, INetAddress.
Super fjollet, spild af tid og unødvendig ekstra kode som ikke er kombatibelt med API'ets andre standard objekter/metoder.
Det er lidt ligesom File.Open() er gud for mig i .NET, alt den kode og exception catching der skal til I Java er virkelig horribelt at arbejde med. (Samt hele problemet med classpath og IO i java, men det er en anden diskussion.)
Windcape (26) skrev:En af mine medstuderende havde skrevet en IPAddress klasse i Java.... uden at havde undersøgt om der allerede var en i API'et, INetAddress.
Jeg snakker om bevidste valg, og ikke newbies der ikke aner hvad de laver. ;-)
Jeg ser det absolut ikke som sidste nødløsing.
Tænk på det på denne måde: Du siger selv du foretrækker et sprog, som giver dig mulighed for at benytte den besværlige metode. Hvad nu, hvis du benytter den besværlige måde mange gange, på samme måde. Hvorfor ikke pakke det ind i en convenience-something? Bare fordi der er en i forvejen, er det jo ikke sikkert at den dækker dit behov. Det har du jo fundet ud af. Men det betyder jo ikke, at man ikke kan lave en anden som gør.
Jeg synes på mange måder det han siger er korrekt, men det er bare først blevet korrekt i løbet af de sidste år. Med det mener jeg, at Ruby helt sikkert er et rigtigt godt sprog, men det kan bare aldrig sidestilles med C/C++ hvad angår proformance. Det der er sket er dog, at vores PC'er er blevet så kraftige, at proformancen på 95% af software til den platform ikke er højt prioriteret længere. Derfor er det fint nok nu, at sige, at vi skal holde op med at fokusere så meget på compileren, da en PC i dag eksikverer fortolket sprog hurtigere end en 5 år gammel box eksikverer compiled C/C++
Fremtiden kommer til at byde på endnu mere "dagligdagstale programmeringssprog" og det er da bare super dejligt. C# var jo et kæmpe spring fremad fra C++ og der kommer mange flere og størrer spring. Det han bare glemmer er, når man skriver kode til en 100 - 200mhz processor med 54kb ram, så kan man altså ikke bruge et "flot - tegn og forstå - sprog, så er man altså i C eller lignende.
Fremtiden kommer til at byde på endnu mere "dagligdagstale programmeringssprog" og det er da bare super dejligt. C# var jo et kæmpe spring fremad fra C++ og der kommer mange flere og størrer spring. Det han bare glemmer er, når man skriver kode til en 100 - 200mhz processor med 54kb ram, så kan man altså ikke bruge et "flot - tegn og forstå - sprog, så er man altså i C eller lignende.
Hr. Ola tilslutter sig den betydelige horde af compilerfolk, der igennem årene har kommet med udmeldingen om at "man skal kode via resultat og aktøre" og ikke "via compiler og computer". Der er derfor også lavet utallige forsøg på disse sprog og fællestegnet for dem, er at de indtilvidere alle hører under kategorien "epic fail!".
Hvis man vil se nogle gode eksempler på, at vi i virkeligheden ikke er kommet særlig langt i denne henseende, så kan man jo kigge på Java og C#, som der pt. er defacto indenfor RAD-udvikling. Begge to er i virkeligheden blot C++, der har fået GC, et fyldigt framework og en IDE der kan hjælpe med "god kodestandard" og intellisence mm.
Dette er natuligvis fremragende forbedring af C++ mht. vedligehold og udvikling, men man tænker og koder stadigvæk på nøjagtig samme måde, som når man skriver C++.
#10 Jeg kan også lave min egen memory management, tråde, asm, pointere o.s.v. i VB6. (Not kidding) Og modsat C++, så kan man også få automatisk GC i VB6. Men det betyder jo hverken at VB6 er bedre end C++, eller at VB6 er et godt sprog i det hele taget.
Hvis man vil se nogle gode eksempler på, at vi i virkeligheden ikke er kommet særlig langt i denne henseende, så kan man jo kigge på Java og C#, som der pt. er defacto indenfor RAD-udvikling. Begge to er i virkeligheden blot C++, der har fået GC, et fyldigt framework og en IDE der kan hjælpe med "god kodestandard" og intellisence mm.
Dette er natuligvis fremragende forbedring af C++ mht. vedligehold og udvikling, men man tænker og koder stadigvæk på nøjagtig samme måde, som når man skriver C++.
#10 Jeg kan også lave min egen memory management, tråde, asm, pointere o.s.v. i VB6. (Not kidding) Og modsat C++, så kan man også få automatisk GC i VB6. Men det betyder jo hverken at VB6 er bedre end C++, eller at VB6 er et godt sprog i det hele taget.
illishar (33) skrev:så kan man jo kigge på Java og C#, som der pt. er defacto indenfor RAD-udvikling. Begge to er i virkeligheden blot C++, der har fået GC, et fyldigt framework og en IDE der kan hjælpe med "god kodestandard" og intellisence mm.
Dette er natuligvis fremragende forbedring af C++ mht. vedligehold og udvikling, men man tænker og koder stadigvæk på nøjagtig samme måde, som når man skriver C++.
Det mener jeg ikke er helt rigtigt. Java/C# og C++ programmerings stil har udviklet sig i forskellige retninger. Ved diskussioner mellem C# og C++ programmører mener jeg klart at man kan se at de tænker forskelligt.
interfaces - generel og multipel arv
generics - templates
maintenance - performance
reflection, DI etc.
o.s.v.
#35 ...og hvilke fordele giver det, at være tæt på compileren?!??
Problemet er,a t vi har enorme industrier, der bruger en masse på ressourcer på ligegyldige if/else-sætninger, istedet for en meget mere forretningsnær udvikling.
Grunden til SOA vinder så meget frem (udskældt eller ej), er jo at oven på kransekagen står BPM og venter som en lækkerbidsken, hvor vi lige pludselig har forretningseksperter, der kan stykke forretningsflows samme, så forretningen bliver understøttet af sin IT-installation, og med en TTM der er minimal - istedet for at det er tiden det tager at udvikle/omdanne et system, der bestemmer forretningens tempo.
(Ja - jeg er godt bekendt med den lange træge vej, til dette drømmescenarie...ikke desto mindre mener jeg at BPM-lignende systemer giver forretningen magten tilbage).
Jeg forstår udmærket Bini, og hans pointer - når man tænker på modenheden i C++, som Java har stillet sig oven på, og sidenhen .NET har tilsluttet sig, så er det langt hen ad vejen ikke meget forretningshensyn de har tilvejebragt.
Problemet er,a t vi har enorme industrier, der bruger en masse på ressourcer på ligegyldige if/else-sætninger, istedet for en meget mere forretningsnær udvikling.
Grunden til SOA vinder så meget frem (udskældt eller ej), er jo at oven på kransekagen står BPM og venter som en lækkerbidsken, hvor vi lige pludselig har forretningseksperter, der kan stykke forretningsflows samme, så forretningen bliver understøttet af sin IT-installation, og med en TTM der er minimal - istedet for at det er tiden det tager at udvikle/omdanne et system, der bestemmer forretningens tempo.
(Ja - jeg er godt bekendt med den lange træge vej, til dette drømmescenarie...ikke desto mindre mener jeg at BPM-lignende systemer giver forretningen magten tilbage).
Jeg forstår udmærket Bini, og hans pointer - når man tænker på modenheden i C++, som Java har stillet sig oven på, og sidenhen .NET har tilsluttet sig, så er det langt hen ad vejen ikke meget forretningshensyn de har tilvejebragt.
#37
LINQ bringer dig et skridt videre end SQL, men der er stadig kvantespring til BPM.
...jeg erindrer ikke at jeg have skrevet at Java var mere forretningsnært end .NET?!??
Problemet for sprogene er nøjagtig de samme, set ud fra et forretningsmæssigt perspektiv.
Forretningen kan kun flytte og forandre sig, i den hastighed den understøttende IT kan følge med - når alting mere eller mindre skal skrives fra bunden, og ikke blot er nogle standardiserede processer, der forbindes til nye arbejdsgange og procedure.
LINQ bringer dig et skridt videre end SQL, men der er stadig kvantespring til BPM.
...jeg erindrer ikke at jeg have skrevet at Java var mere forretningsnært end .NET?!??
Problemet for sprogene er nøjagtig de samme, set ud fra et forretningsmæssigt perspektiv.
Forretningen kan kun flytte og forandre sig, i den hastighed den understøttende IT kan følge med - når alting mere eller mindre skal skrives fra bunden, og ikke blot er nogle standardiserede processer, der forbindes til nye arbejdsgange og procedure.
#14
Jeg er meget enig.
Jeg tror ikke på "This is the Master-Language, the One Language to rule them all" filosofien.
Vi kan se med PL/I og Ada hvordan det går.
Desværre synes både Java og .NET verdenen lige p.t. at tro på flere features => bedre sprog paradigmet.
Det fortryder de nok om 10 år.
Jeg er meget enig.
Jeg tror ikke på "This is the Master-Language, the One Language to rule them all" filosofien.
Vi kan se med PL/I og Ada hvordan det går.
Desværre synes både Java og .NET verdenen lige p.t. at tro på flere features => bedre sprog paradigmet.
Det fortryder de nok om 10 år.
michaelbarner (17) skrev:Er ikke mere kompliceret end at moderne, gode, programmeringssprog kommer med en masse forud-skrevne objekter til gængse opgaver, mens man i f.eks. Java er nødt til at skrive næsten al sådan kode selv.
Java SE standard API indeholder 3288 klasser med 97480 metoder.
Java EE standard API indeholder 1075 klasser med 19359 metoder.
Jeg tror at du skal studere Java libs en lille smule.
michaelbarner (17) skrev:Sidder lige nu med en Java-app, hvor selv DataTable-objektet er hjemmeskrevet, suk! I mere moderne sprog er hele dataadgangen f.eks. lagt ud i medleverede objekter, hvad der unægteligt er en hel del lettere at gå til.
Det er jo ikke Java's skyld at:
* nogen har valgt et tvivlsomt design pattern (DataTable)
* samme nogen har valgt at implementere det via egen klasse i.s.f. at bruge den indbyggede i Java (RowSet)
Og der er frit valg fra alle hylderne med hensyn til persistering:
SQLJ
JDBC ResultSet
JDBC RowSet
entity bean BMP
entity bean CMP
JDO
JPA
Hibernate
iBatis
etc.
Det eneste som det kræver er at man sætter sig en lille smule ind i tingene.
#19,21,23-27
Java og .NET udvikles udfra meget forskellige filosofier.
Folkene bag .NET har Balmer stående og hoppe på deres krivebord og råbe "developers developers". Det er en top prioritet at gøre det nemt for udviklerne.
Folkene bag Java har nogen gange en holdning som "Har det været svært for os at finde på så skal de også være svært for dem som skal bruge det". Tingene skal laves på den rigtige måde og så er det ligegyldigt om det er nemt eller ej.
Derfor har Java ikke File.ReadAll* etc..
Det er ikke et problem for Java projekter i den virkelige verden. Det tager ingen tid at skrive de 5-10 linier. Og sandsynligvis har man allerede noget liggende på lageret.
Men det kan godt irritere i skole projekter.
Generelt med hensyn til forskellen i filosofi er det efter min mening ofte en fordel at gøre tingene rigtigt - med passende SPI's defineret etc., men der er dog eksempler hvor de efter min mening er gået over gevind. Det nye compiler API er efter min bedste overbevisning overengineered.
Java og .NET udvikles udfra meget forskellige filosofier.
Folkene bag .NET har Balmer stående og hoppe på deres krivebord og råbe "developers developers". Det er en top prioritet at gøre det nemt for udviklerne.
Folkene bag Java har nogen gange en holdning som "Har det været svært for os at finde på så skal de også være svært for dem som skal bruge det". Tingene skal laves på den rigtige måde og så er det ligegyldigt om det er nemt eller ej.
Derfor har Java ikke File.ReadAll* etc..
Det er ikke et problem for Java projekter i den virkelige verden. Det tager ingen tid at skrive de 5-10 linier. Og sandsynligvis har man allerede noget liggende på lageret.
Men det kan godt irritere i skole projekter.
Generelt med hensyn til forskellen i filosofi er det efter min mening ofte en fordel at gøre tingene rigtigt - med passende SPI's defineret etc., men der er dog eksempler hvor de efter min mening er gået over gevind. Det nye compiler API er efter min bedste overbevisning overengineered.
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
- ⟨
- Nyheder
Gå til bund