Borland med på .NET udviklingsbølgen

#1 - Disky
30. jan. 2003 08:23

Så må vi da håbe de snart 'igen' har lært at lave ordentlige værktøjer.

Turbo Pascal var det sidste gode værktøj de lavede, ting som f.eks. JBuilder er håbløst besværlige at bruge, og meget lidt intuitive, sammenlignet med andre værktøjer.

#2 - mikbund
30. jan. 2003 08:29

HHmmm synes nu eller jeg har hørt meget godt om deres delphi pakke...

Hver sin smag vel.

#3 - Disky
30. jan. 2003 08:30

Okay lige delphi har jeg aldrig rodet med, men deres andre værktøjer har jeg aldrig været imponeret over siden Turbo Pascal.

#4 - mikbund
30. jan. 2003 09:02

"Okay lige delphi har jeg aldrig rodet med, men deres andre værktøjer har jeg aldrig været imponeret over siden Turbo Pascal."
Nu er delphi jo også kun forsætteren til Turbo Pascal, og et af de produkter som har været længst tid på banen.
Igen, hver sin smag :-)

#5 - Disky
30. jan. 2003 09:40

Hej igen.

Du har ret i man har sin egen smag, nu har jeg intet imod Delphi ud over jeg ikke gider rode med det.

Men det er kvaliteten af specielt JBuilder jeg er harm over.

Mange bliver tvunget til at bruge det værktøj, selvom mange open source gratis værktøjer er langt bedre.

#6 - mikbund
30. jan. 2003 09:45

Men det er kvaliteten af specielt JBuilder jeg er harm over.
Tja det kan jeg ikke rigtig udtale mig om, har aldrig prøvet det, jeg er kun minislamkoder :-)

Mange bliver tvunget til at bruge det værktøj, selvom mange open source gratis værktøjer er langt bedre.

Jeg forstår ikke helt tvangen, men okay, jeg er heller ikke koder og arbejder ikke med det. Der kan du nok enlighten mig :-)

#7 - Disky
30. jan. 2003 09:52

Mange virksomheder, tror at borland's produkter er top of the line.

Og derfor skal ALLE bare tvinges til at bruge det værktøj, istedet for det vørktøj de eventuelt arbejdet bedst sammen med.

På mit første job efter jeg blev ingeniør skulle jeg med al vold og magt lave java udvikling i Emacs editoren. Den er sikkert hel fin, men når man er har erfaring med komplete IDE'er og ikke bare en æld gammel editor, så er man extremt begrænset. Og derved arbejdede jeg også en del langsommere. På et tidspunkt fik jeg endelig lov at skifte til Forte fra SUN, og pludselig væltede koden ud :)
Min chef måtte indrømme, at det at tvinge en udvikler ind på et bestemt værktøj er sjælden en god ide.
Desværre er de færreste chefer så kloge :(

p.s. Jeg har intet imod Emacs, bare jeg slipper for at skulle bøvle med den.

#8 - _VeNtUrAx_
30. jan. 2003 10:05

Syntes det er fedt at der kommer alternativer til MS Visual Studio. Bare så alle udviklere der er kendt med andre systemer ikke skal migrere til Windows.

Håber dog for Borland at deres .NET IDE bliver noget mere stabilt end C++ Builder og JBuilder. IDE't crasher konstant og kommer med mystiske fejl, som for et meste ikke betyder noget.

#7: TRUE!!!
Da jeg blev ansat efter det samme studie :o), blev jeg tvunget til at skulle arbejde med Borlands C++ Builder 5. Men efter at have brugt BCB 5 et ½ års tid, så jeg lyset (Visual SlickEdit). Og det bruger jeg idag... både til Linux og Windows. Kunne ALDRIG finde på at skifte til noget andet.

/V

#9 - Disky
30. jan. 2003 10:15

venturax:
Har du en link til det værktøj ?

Jeg bruger normalt selv Forte, men er ved at skifte til IntelliJ, pga. den super seje refactoring, og avancerede codestyle fixer.
Og den har 117 små ting der gør den super.

#10 - sKIDROw
30. jan. 2003 10:26

#7 Disky

"På mit første job efter jeg blev ingeniør skulle jeg med al vold og magt lave java udvikling i Emacs editoren. Den er sikkert hel fin, men når man er har erfaring med komplete IDE'er og ikke bare en æld gammel editor, så er man extremt begrænset. Og derved arbejdede jeg også en del langsommere. På et tidspunkt fik jeg endelig lov at skifte til Forte fra SUN, og pludselig væltede koden ud :)"
Nogle opgaver løses jo også nemmere med en skruemaskine, hvor andre bedst klares med en alm. phillips skruetrækker.. ;)

"Min chef måtte indrømme, at det at tvinge en udvikler ind på et bestemt værktøj er sjælden en god ide.
Desværre er de færreste chefer så kloge :("
Det er nogle gange lidt svært at vænne dem af med.. :o/

"p.s. Jeg har intet imod Emacs, bare jeg slipper for at skulle bøvle med den."
Tjahh
Og Richard Stallman lavede Emacs fordi han ikke var fan af VI.. ;)

#11 - Hektor
30. jan. 2003 10:48

#9 Disky:
"Jeg bruger normalt selv Forte, men er ved at skifte til IntelliJ, pga. den super seje refactoring, og avancerede codestyle fixer."

Ahh ... de måtte godt fikse lidt ved rename-delen ... jeg skulle rename en metode, og jeg skulle PINE DØD tvinges til at ændre i en STRENG, der absolut intet havde med metoden at gøre ...

"Og den har 117 små ting der gør den super."

True that. True that. Jeg er solgt for længst.
Eneste jeg lige mangler at finde, er autogenerering af javadoc ... har tags osv. i koden - mangler bare lige at få den til at generere det for mig.

Hmm ... det kan Ant sikkert gøre ... :-)

#12 - GreatMilenko
30. jan. 2003 12:36

Det er syndt for jer at i aldrig har prøvet at programmere i Delphi, men too bad i kommer aldrig til at opleve det bedste værktøj til at udvikle og designe GUI'er på. Til gengæld er i med på Java bølgen HURRAA så kan i lave GUI'er i Emacs og få jobs en masse steder hvor de også skal være med på bølgen, indtil de en dag må dreje nøglen om fordi i har brugt 10 gange så lang tid på at lave arbejdet.......

#13 - Hektor
30. jan. 2003 12:45

#12 GreatMilenko:
Øhh ... nå. I 18 måneder har jeg måske brugt 3% af min tid på at lave GUI.

#14 - Disky
30. jan. 2003 13:08

greatmilenko:
Ja hurra, vi er helt vildt kede af vi har arbejdet med et sprog der IKKE er låst til en platform, og som bestemt ikke er død.

GUI er en FORSVINDENDE lille del af softwaren. Jeg har arbejdet prof. med Java udvikling siden 1/7 2000, og jeg har endnu IKKE lavet det mindste GUI i Java.

Men havde jeg gjort det, ville jeg vide at det også kørte fint på windows, linux, mac, PDA'ere osv. Prøv lige at gør det med Delphi.

Undskyld jeg siger det lige ud, men du ved ret tydeligt ikke hvad du snakker om når det drejer sig om java fordele/ulemper i forhold til delphi.

Delphi er sproget hvor en nybegynder eller dårlig udvikler kan lave noget der ser fancy ud, men forresten ikke aner en brik om hvad der foregår nedenunder.

#15 - mikbund
30. jan. 2003 13:34

Disky:
Blot fordi silentmilenko sænker nivaeut til under jordgrænsen behøver du vel ikke falde i, når du ikke selv har hold i dine flames!

Hvis vi skal flame kan vi også gøre det om Java:
Java:
Langsom afvikling
Dårlige udviklingsværktøjer
Der skal installeres en Java fortolker for at det kører
Microsoft har forsøgt at ødelægge standarden

Delphi:
Låst til en platform(windows)
behandling af pointere
[kom med flere]

#16 - seahawk
30. jan. 2003 13:55

Ej - ikke gøre det til en flametråd - nu er den nogenlunde dejlig fri for rottebørn(Fordi vi er voksne mennesker der snakker om ting de færreste af dem har forstand på! :))

Delphi: Dejligt udviklingsmiljø - men sproget(Object Pascal) er noget hø at rode med(men jeg er også inkarneret c/c++) mand. Min største anke ved det er at pointers er nogenlunde fjollede at have med at gøre(Ja, man HAR brug for pointers i visse sammenhænge)

C++ Builder: Har ikke arbejdet forfærdeligt meget med det, så jeg skal ikke kunne sige om det er ustabilt. Men ellers minder det meget om Delphi, bare med et sprog jeg personligt synes bedre om. Lækkert IDE imho.

MS VS 6: En rimelig hurtig compiler og ganske fornuftigt at arbejde med, men ikke noget jeg vil anbefale til GUI udvikling.

MS VS .NET: Lækkert, omend et MEGET tungt udviklings miljø. Har kun lavet ting i C# i det, men jeg formoder ikke at der er mindre lækkert i de andre sprog, men det ER altså meget krævende af maskinen, og har en tendens til at låse hvis man udvikler op mod en ekstern server(i ASP.NET).

Java udviklings miliøerne har jeg ikke professionel erfaring med, alle de gange jeg har PRØVET at bruge dem personligt er jeg blevet jævnt frustreret over de ganske enkelt kører for langsomt!

Det kan godt være at java på alle måder er en lækker ting, men platformsuafhængigt gui er bare ikke godt nok.

Til alle platformsspecifikke GUI programmer vil jeg til enhver tid bruge C++ Builder/VS.NET c#), og til enhver form for service ville jeg foretrække java(og bruge jedit).

Det er selfølgelig bare min holdning, men een ting er sikkert - der er INTET sprog/IDE der er det ultimative - de har alle forskellige styrker og svagheder - så folk der kategorisk vælger det samme hver gang begår helt sikkert en fejl)

#17 - Disky
30. jan. 2003 14:23

Mikbund:

Langsom afvikling:

Langsommere end native kode ja, det er den lille pris man betaler for platformsuafhængighed, men den er det værd.

Dårlige udviklingsværktøjer

De værktøjer der findes er helt på højde med Delphi, C++, C, Cobol og andre sprog.

Der skal installeres en Java fortolker for at det kører
Microsoft har forsøgt at ødelægge standarden

Det skal man også ved Delphi, der skal man havde en stor bunke .dll filer med.

At microsoft har forsøgt at ødelægge standarden er helt klart irriterende, men det var vel også den eneste måde .net på clienten havde en chance.

#18 - seahawk
30. jan. 2003 14:36

#17:

Langsommere end native kode ja, det er den lille pris man betaler for platformsuafhængighed, men den er det værd.
Det kommer jo an på i hvilken sammenhæng! Jeg kan da sagtens forestille mig steder hvor jeg ikke kan acceptere at koden kører med halv hastighed fordi det er java...

#19 - GreatMilenko
30. jan. 2003 14:36

Jeg udvikler selv med C++ i Visual studio på min arbejdsplads, og dette er netop en af grundende til at jeg vælger at arbejde med Delphi privat eftersom der kan jeg selv vælge det værktøj som der er bedst. At i ikke kan finde ud af at bruge pointere i Delphi, well det er jo bare sur røv for jer. Men det er rigtigt at i langt de fleste tilfælde er det ikke nødvendigt direkte at sidde og fedte med en pointer, undtagen når man skal kalde noget c kode såsom windows. Jeg tror personligt at det er en fordel at gemme det mest muligt for folk, jeg er for ofte stødt på memory leaks eller pointere der peger henimod røven af 3 division.
Streng rutinerne i c/c++ er feks. en joke, det kan ikke være rigtigt at man skal manuelt allokere og deallokere hukommelsen hvis du lægger to strenge sammen, det skal ske i en streng klasse med operator overload som feks. stl's string klasse, problemet er hvis du sidder med en blanding af de to så kan du glemme alt om at lægge dem sammen da det så er en string+char* og det går ikke. Og folk har en tendens til at lave deres egen streng klasse da de ikke mener at stl's er god nok, resultatet er så et hav af forskellige strengklasser der ikke er kompatible jubiii!
Men hvis du fra starten har gennemtrumfet een string klasse der bliver brugt i alle versioner af sproget så er du ude over de problemer..
Desuden kan Delphi også fås til linux, der hedder den kylix.

så:
Delphi:Låst til en platform(windows): nejbehandling af pointere: ja dem kan du godt benytte men du behøves ikke

Hektor: øøhhnå men tillykke med dit nye command line tool.

Der skal installeres en Java fortolker for at det kører
Microsoft har forsøgt at ødelægge standarden
Det skal man også ved Delphi, der skal man havde en stor bunke .dll filer med.

Medmindre man laver et standalone build, men nu skal vi ikke kræve for meget.

#20 - Disky
30. jan. 2003 14:46

greatmilenko:
Java har et suveræn String håndtering indbygget.

Der er faktisk en stor fordel ved at men selv skal allokerer/deallokerer i C/C++, nemlig performance.

Selvfølgelig kan man lave et standalone build i Delphi, men så fylder det også noget mere, tager længere tid at downloade, og du ender op med det samme data ligger 17 forskellige stedet på din HD og fylder.

Ja delphi findes til kylix, men er stadigvæk IKKE platformsuafhængigt, eller kan du måske flytte et eksekverbart Delphi program fra windows til linux, og så kører det stadigvæk ? Mig bekendt ikke, du kan måske rekompile sourcekoden, men det er ikke det samme som platformsuafhængighed. Eller hvad med at lave en skrabet delphi udgave og så eksekvere det på din Nokia 3410 telefon kan man det ? Det kan man med Java :)

Delphi er et fint sprog, men meget mere end et niche produkt er det aldrig blevet til, om dette så er godt eller skidt, skal jeg ikke svare på, men jeg savner det nu ikke.

#21 - stone
30. jan. 2003 15:12

#15 #17 #18 - om java koerer langsommere kan diskuteres. for at afvikle et program skal der noget virtuel maskine igang med noget fortolkning, og det tager naturligvis tid. men naar foerst programmet koerer, er det lige saa hurtigt som native kode paa de fleste punkter, og i nogle tilfaelde hurtigere.

naar foerst bytekoden er fortolket, bliver det jo et spoergsmaal, om den kode den generere er bedre end det en given c++, eller ligenden, compiler kan fremstille.

i mange tilfaelde kan runtime enviroment'et drage fordel af at koden ikke er pre-compileret, og optimere realtime til den givne platform og de forhold den afvikles under.

det er dog klart at det kraever en del ram og cpukraft, men java er for saa vidt ikke langsomt.

/stone

#22 - seahawk
30. jan. 2003 15:20

#21:

Dokumentation, tak! ALLE benchmarks jeg har set, kører java ca. med halv hastighed!

Og ang. delphi: At sige at pinter håndtering ikke er brugbart, så prøv lige at lave ændringer direkte i et bitmap, og lave noget koder der er bare halvt så hurtigt som i c med pointer aritmetik... Jeg kunne ikke, og ingen af de delphi programmører(Her snakker folk som har været officielle borland betatestere siden delphi startede), kunne heller ikke!

Delphi ER platformsafhægigt sidst jeg kiggede... For at modbevise mig, vil jeg gerne have du laver et lille ur som IKKE kræver qt... :o)

Derudover er CLX komponeterne langt fra lige så komplette som VCL!

Ang. strings - ja, det ser ikke kønt ud i c/c++, og det er RART at man bare kan lægge dem sammen i java/delph/c#, men der er kode hvor du gerne vil have 100% kontrol over den slags!

Som sagt - forskellige udviklings milliøer har forskellige forcer.

#23 - sguft
30. jan. 2003 15:25

Disky: Du er tydeligvis ikke en hujende fis inde i Delphi.
Der er rent faktisk en del firmaer der arbejder professionelt med Delphi, også herhjemme.

Delphi har den fantastiske egenskab at skal du lave et produkt der hovedsageligt skal indeholde en GUI og kobles op imod en Database, jamen så kan det gøres på under den halve tid af alle andre udviklingsværktøjer/sprog (pånær C++Builder der bygger på Delphi's classlibary og i bund og grund er samme editor).
Dvs. det bliver hovedsageligt brugt til applikationer hvor GUI er i højsædet (det kan man vist ikke ligefrem sige om Java).

"Ja delphi findes til kylix, men er stadigvæk IKKE platformsuafhængigt, eller kan du måske flytte et eksekverbart Delphi program fra windows til linux, og så kører det stadigvæk ? Mig bekendt ikke, du kan måske rekompile sourcekoden, men det er ikke det samme som platformsuafhængighed. Eller hvad med at lave en skrabet delphi udgave og så eksekvere det på din Nokia 3410 telefon kan man det ? Det kan man med Java :)"

Jamen hvem har dog også nogensinde bildt dig ind at det er meningen at Delphi skal være platformsuafhængigt? Delphi arbejder på samme niveau som C++ og er sjovt nok ikke mere platformsuafhængigt end at du skal kompilere 2 versioner af den source kode for at få den til at køre under henholdsvis Linux og Windows.

Desuden står platformsuafhængighed meget langt nede på min prioriteringsliste medmindre produktet ligefrem kræver det. Ellers udvikler jeg kun til Windows og det er der nogle ganske gode grunde til, vigtigst af alt, målgruppen.

Men nu bliver det med .NET og Delphi 7/8 (7 er forberedt .NET men det vil først være fuldt integreret i 8)også muligt at kode platforumsuafhængigt fra Delphi, så er alle vel glade og så kan det sjovt nok også afvikles på PDA'er, mobiltelefoner etc etc som i fremtiden kommer til at understøtte .NET platformen.

Men ja for at afrunde det må jeg indrømme at jeg typisk prioriterer afviklingshastighed, GUI og udviklingstid højere end platformsuafhængighed, derfor falder mit valg sjældent på Java. Men pointen er vel lidt at man bør vælge det sprog der passer bedst til opgaven. Er platformsuafhængighed et must .. ja så er der Java og .NET at vælge imellem. Skal produktet kobles op imod et bestemt OS er du bedre tjent med f.eks. C++ eller Delphi.

(og ja, jeg er elendig til at fatte mig i korthed :p)

#24 - bustermaniac
30. jan. 2003 16:47

hehe, så er der religionskrig igen :P. Tag dog og slap af. I ved jo udemærket godt at man ikke kan pege på et sprog og sige at det er det bedste. Delphi fungerer fint til mange ting, men det samme kan man sige om JAVA. Den umidelbare forskel mellem de to er vel at JAVA-sproget kompileres til nogle platformsuafhængige filer hvor Delphi/C++ builder ikke gør. Det er dog muligt at finde kompilere til mange andre sprog der kan kompilere til JAVA bytecode - f.eks. pascal varianten Component Pascal. Det kan man så vælge at gøre hvis man vil benytte JAVAs platformsuafhængighed.

En ting som i glemmer er, at med Borlands nye .NET muligheder, vil det gøre Delphi, og Object Pascal, langt mere platformsuafhængigt. Ja, måske ikke i samme grad som med JAVA, men da .NET er blevet standardiseret så vil det da være nærliggende at forsøge sig med det.

#25 - mikbund
30. jan. 2003 22:33

Lige for at flame lidt. Der var en anden tråd for nylig med vidfone som mente at fuld platformsuafhængighed i Java ikke var sandt alligevel.

Nogen der kan komme med lidt mere seriøse fremlæg...
Jeg synes Java er godt med platformsuafhængigheden, men hvis den ikke passer, hvorfor så kode i JAVA. C/C++ kan det hele i såfald. Fordele og ulemper ved sprogene, anyone?

#26 - stone
31. jan. 2003 00:31

#22 - hvorfor forlanger du dokumentation fra mig naar du selv kun kommer med paastande? under alle omstaendigheder tror jeg vi snakker om 2 forskellige ting. jeg skriver ingen steder at et java program vil koere lige saa hurtigt som et native compiled program. det jeg forsoeger at sige er i bund og grund, at hvis du laver et simpelt program, der f.eks. bare laver en stribe simple matematiske beregninger, vil det koere lige saa hurtigt i java - det skyldes naturligvis at naar foerst en programstump er blevet parsed og compiled, hvad enten det er sket paa forhaand af en compiler, eller at runtime env. lige har gjort det, vil dine loekker og beregninger blive optimeret til ca. det samme paa cpu'en. her er det saa at runtime env. i nogle tilfaelde kan vinde lidt, da den kan optimere mens kodens afvikles.

dette er naturligvis ikke det samme som at et java program afvikles lige saa hurtigt som eks. et c++ program. for det foerste skal det fortolkes, for det andet forsvinder der meget hastighed naar den skal til at oprette flere objekter og garbage-managege dem, samt caste typer med mere.

haaber min pointe staar lidt tydeligere frem nu.

/stone

#27 - stone
31. jan. 2003 00:39

#25 - platformsuafhaengighed er skam rigtigt nok.

naar du staar med et javaprogram, er det et spoergsmaal om at det skal parses. det kraever selvfoelig et program, og det findes naturligvis ikke til alle platforme. eksempelvis findes der ikke en (ordenlig) java virtuel maskine til amiga. men saa er java ikke platformsuafhaengigt? det koerer jo ikke paa amiga? naeh, men det er et spoergsmaal om en vm der kan afvikle programmet. selve koden indeholder intet der goer den afhaengig af en given platform, cpu eller ligende, hvormed den er platformsuafhaengig.

/stone

#28 - Ekbatana
31. jan. 2003 01:28

platformsuafhaengighed...

supernintendo rom'filer kan efterhånden køres på de fleste maskiner ved hjælp af emulatorer, eller virtual machines du vil..tror også at de kan køre på amiga.. så derfor må snes maskinkode være platformsuafhængigt og altså det optimale udviklingsmiljø..skidt med at det kører langsomt og højst kan køre med 8bit farver.. (ikke helt alvorligt ment..)

java.. jeg undgår normalt java-programmr som var det pesten, blandt andet fordi de er langsomme.. den tid man spilder på at vente på parseren kunne udviklerne havde brugt på at lave platformsafhængig kode og jeg på selv at compile lortet..

#29 - sguft
31. jan. 2003 07:25

#28: Hvem har bildt dig ind at det er langsommere at lave platformsafhængig kode ? :)

#30 - seahawk
31. jan. 2003 12:55

#22:

http://mathsrv.ku-eichstaett.de/MGF/homes/grothman...
http://research.sun.com/people/mario/java_benchmar...

For bare at nævnte de første par stykker jeg faldt over...

Men lad mig vende den om - hvis java er lige så hurtigt som c++, og er meget lettere at programere til(Det vil jeg mene det er), hvorfor bliver de mest performancekrævende applikationer(spil) ikke skrevet i java?

Hvis der ikke er performance som grund kan jeg ikke se det, da spil ikke bruger gui(Som JEG mener er javas største problem)

:)

#31 - Hektor
31. jan. 2003 13:20

#30 seahawk:
Den første ville jeg smide over højre skulder, da den nyeste JVM i testen er 1.1.7, som er adskillige år gammel.

Kan ikke lige gennemskue den anden side.

Men - det er interessant at steder som CERN, har implementeret adskillige talbehandlings-libraries i java (http://hoschek.home.cern.ch/hoschek/colt/), hvis java er langsommere end f.eks. C++. Med de run-tider, som CERNs datasæt vil have, så vil en forskel på 1% give en pæn forskel. Hvis det tager én dag, at lave det hurtigtste gennemløb, vil en forbedring på 1% skære et kvarter af den tid. 10% vil skære næsten 2½ time af det.

I MANGE henseender er valget af algoritme og programmørens evner betydeligt vigtigere end sprogets teoretiske ydelser.

#32 - seahawk
31. jan. 2003 13:57

#31:

Ja, men jeg kunne desværre ikke finde nogen nyere! :(

Og ja - programmøren betyder mere end sproget det skrives i! :)

Men for en gangs skyld er det jo en tråd rimelig fri for rottebørn, så alle os der snakker er jo guds gave til programmørstanden, ikke sandt? ;oD

#33 - Ekbatana
31. jan. 2003 17:47

#29 ...okay måske ikke lige det rigtige ord..
det jeg mener er "source level" uafhængig c/delphi/ og ellers linke de rigtige steder hen ved compile time..
hvilket vel tager lidt længere tid at skrive...

#34 - sguft
1. feb. 2003 10:23

#33: Ikke nødvendigvis hvis du f.eks. benytter Delphi 6 eller bedre sørger miljøet selv for at inkludere de rigtige libaries alt efter om du compiler til linux eller windows og med en af verdens hurtigste compilere når du ikke engang at ligge mærke til den spytter en exe ud ;)

Så det er vist ikke der tidsplanen overskrides :)

Men ja, benytter du C/C++ er det da noget mere besværligt, det gælder for den sags skyld så meget i de sprog, men det er prisen for den store flexibilitet i sprogene.

mboost-dp1

Nyheder

Seneste kommentarer i nyheder

Seneste kommentarer i forum

Borland med på .NET udviklingsbølgen