mboost-dp1
unknown
Lyder interessant, ja jeg er med i de 59% (tvunget af arbejdsgiver).
Når Mono så understøtter .Net 2.0 100% så begynder det at blive spændende.
Samt at MySQL skal tage og blive færdige med deres add-on til VIsual Studio, så man kan bruge MySQL på samme nemme måde som f.eks. Jet eller MsSQL.
Når Mono så understøtter .Net 2.0 100% så begynder det at blive spændende.
Samt at MySQL skal tage og blive færdige med deres add-on til VIsual Studio, så man kan bruge MySQL på samme nemme måde som f.eks. Jet eller MsSQL.
Ved godt det er ret offtopic, men det overrasker mig meget at 59% af .NET udviklere kun bruge VB.NET.
Jeg synes jeg kender en del udviklere, og det er kun få af dem der kunne finde på at skrive i VB.NET, og selv de kan også godt skrive C#.NET (som alle vi andre foretrækker). :)
Sorry for offtopic, men måtte bare ud med det.
Jeg synes jeg kender en del udviklere, og det er kun få af dem der kunne finde på at skrive i VB.NET, og selv de kan også godt skrive C#.NET (som alle vi andre foretrækker). :)
Sorry for offtopic, men måtte bare ud med det.
Da jeg skrev nyheden var jeg lidt i tvivl, og tog det derfor ikke med. Men betyder det her ikke også at det kan køre under OS X? Det er også en platform der understøtter Mono.
Nogen med lidt mere indsigt end mig?
Nogen med lidt mere indsigt end mig?
hmmm... har lidt svært ved at forestille at alt VB kode skulle kunne compiles direkte til linux... Ihvertfald plejer det da at være et problem hvis koden er afhængig af windows.forms i C#... Men bortset fra det er det da positivt, at muligheden nu er der. Men jeg forstår ikke helt hvad så mange (59%) ser i Visual Basic...
Det har intet at gøre med hvad man kan køre på Linux. Man har i forvejen kunne køre .net applikationer på Linux vha. mono. Nu kan man bare også kompilere sin VB.Net i Linux.
Det er jo lige meget om man bruger VB.net eller C#.net osv..
Bliver det samme i sidste ende.
Der er fordele og ulemper i begge.
Hvis man ikke kan læse/kode vb.net kode og c#.net kode..
Så kan man nok ikke rigtig kalde sig for programmør mv.
Bliver det samme i sidste ende.
Der er fordele og ulemper i begge.
Hvis man ikke kan læse/kode vb.net kode og c#.net kode..
Så kan man nok ikke rigtig kalde sig for programmør mv.
#9 og #10
At det bliver compilet til det samme ændrer jo ikke ved at
programmører kan foretrække det ene fremfor det andet eller
at man har et par hundrede tusind linier kode i det ene
som man ikke har lyst til at bruge ressourcer på at
konvertere til det andet (der er tools, men det er
alligevel arbejde).
At det bliver compilet til det samme ændrer jo ikke ved at
programmører kan foretrække det ene fremfor det andet eller
at man har et par hundrede tusind linier kode i det ene
som man ikke har lyst til at bruge ressourcer på at
konvertere til det andet (der er tools, men det er
alligevel arbejde).
#11
Hvilket kan skyldes det så er nemmere at tiltrække Java udviklere.
En C# udvikler kan også nemt skifte til VB.Net og arbejde videre der.
En jobannonce er ligesom børn ønskelister, man skriver alt det op man gerne vil havde, men man får sjældent mere end et par af tingene.
Hvilket kan skyldes det så er nemmere at tiltrække Java udviklere.
En C# udvikler kan også nemt skifte til VB.Net og arbejde videre der.
En jobannonce er ligesom børn ønskelister, man skriver alt det op man gerne vil havde, men man får sjældent mere end et par af tingene.
#14
Job annoncer kan være ret underholdende nogen gange. Når
personale afdelingen ikke helt har styr på alle akronymerne.
Men C# / VB.NET ratioen er ret markant. Dice siger lige
nu 6589 jobs med C# og 2462 jobs med VB.NET !
Hvis de omdiskuterede procenter skal passe, saa er der en 3000
af dem som søger efter C# skills selvom de skal bruge
VB.NET skills.
Det er mange også selvom man har forventninger om at "C#" vil
tiltrække flere Java folk end "VB.NET".
Job annoncer kan være ret underholdende nogen gange. Når
personale afdelingen ikke helt har styr på alle akronymerne.
Men C# / VB.NET ratioen er ret markant. Dice siger lige
nu 6589 jobs med C# og 2462 jobs med VB.NET !
Hvis de omdiskuterede procenter skal passe, saa er der en 3000
af dem som søger efter C# skills selvom de skal bruge
VB.NET skills.
Det er mange også selvom man har forventninger om at "C#" vil
tiltrække flere Java folk end "VB.NET".
nu er kilden nede, men jeg vil alligevel vove at påstå det er 59% af de 37% der kun bruger VB.NET, for det er sgu ikke 59% af alle udviklere der bruger VB.NET. det statement er jo fuldstændig på månen.
og når vi nu er igang, 37% af hvad? af alle udviklere i verden? af alle .NET udviklere? af de 1200 udspurgte personer som de nøje har udvalgt?
og hvordan i alverden kan man komme frem til sådan nogle tal, for jeg har da ikke fået en opringning endnu, så jeg er da vist ikke med i den statestik.
og når vi nu er igang, 37% af hvad? af alle udviklere i verden? af alle .NET udviklere? af de 1200 udspurgte personer som de nøje har udvalgt?
og hvordan i alverden kan man komme frem til sådan nogle tal, for jeg har da ikke fået en opringning endnu, så jeg er da vist ikke med i den statestik.
#13
Så vidt jeg forstår artiklen så er der skrevet en ny VB.NET compiler til de udviklere som bruger Visual Studio. De brugere der bruger Visual Studio har i forvejen en compiler der kan kompilere VB.NET kode til en .NET assembly. Da en .NET assembly bliver JIT kompileret til at køre på den maskine det nu bliver kørt på, i det øjeblik man udfører koden, så skal der altså ikke nogen omkompilering til for at den selvsamme assembly kan køre, lige meget hvilken platform man bruger, så længe den understøtter .NET frameworket.
Når en .NET assembly (Som helt tilfældigvis er skrevet i VB.NET) allerede kan køre på Linux, via MONO, hvad er det så den nye kompiler kan som den gamle ikke kan ?
Så vidt jeg forstår artiklen så er der skrevet en ny VB.NET compiler til de udviklere som bruger Visual Studio. De brugere der bruger Visual Studio har i forvejen en compiler der kan kompilere VB.NET kode til en .NET assembly. Da en .NET assembly bliver JIT kompileret til at køre på den maskine det nu bliver kørt på, i det øjeblik man udfører koden, så skal der altså ikke nogen omkompilering til for at den selvsamme assembly kan køre, lige meget hvilken platform man bruger, så længe den understøtter .NET frameworket.
Når en .NET assembly (Som helt tilfældigvis er skrevet i VB.NET) allerede kan køre på Linux, via MONO, hvad er det så den nye kompiler kan som den gamle ikke kan ?
De skulle hellere bruge kræfterne på at få Mono til at virke. Især deres System.Windows.Forms. (Og jeg er VB-udvikler)
Ligesom med deres .NET 2.0 support. Hvorfor går man igang med at understøtte 2.0 når ens 1.1 praktisk talt ikke virker???
Ja, det er rigtigt at hvis man sætter sig ned og skriver et program med deres Gtk, Wine, Swing (eller hvad de nu end anbefaler) så kan man sikkert godt (efter megen puslen) skruge noget sammen der virker. Tilgengæld vil det være super grimt. Bare kig på de eksisterende Mono-applikationer. Så dårligt er Java altså heller ikke, så man behøves at udsætte sig selv for den slags.
Så hør mit mantra:
VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!!
Ligesom med deres .NET 2.0 support. Hvorfor går man igang med at understøtte 2.0 når ens 1.1 praktisk talt ikke virker???
Ja, det er rigtigt at hvis man sætter sig ned og skriver et program med deres Gtk, Wine, Swing (eller hvad de nu end anbefaler) så kan man sikkert godt (efter megen puslen) skruge noget sammen der virker. Tilgengæld vil det være super grimt. Bare kig på de eksisterende Mono-applikationer. Så dårligt er Java altså heller ikke, så man behøves at udsætte sig selv for den slags.
Så hør mit mantra:
VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!! VIRK NU!!!
#21, du behøver ikke VS for at kompilere .NET kode, SDK'et er mere end rigeligt, der foregår det hele selvfølgelig gennem kommandopromten. Der startede jeg, føj for helvede :)
#23, totalt. Fatter ikke hvad folk vil med VB. Hader det, hader det, hader det.
Kan anbefale et kig på Cuyahoga et open source CMS der kører på .NET og Mono, både med MSSQL, MySQL, og PostgreSQL som backend. Samtidig har de nogle interessante implementeringer. Stadig i babystadige på version 1.5, men det kommer vel :)
#23, totalt. Fatter ikke hvad folk vil med VB. Hader det, hader det, hader det.
Kan anbefale et kig på Cuyahoga et open source CMS der kører på .NET og Mono, både med MSSQL, MySQL, og PostgreSQL som backend. Samtidig har de nogle interessante implementeringer. Stadig i babystadige på version 1.5, men det kommer vel :)
Jeg ville ikke være overrasket over at det er 37% af alle udviklere der bruger VB.Net. Der har tidligere været overraskende mange VB6 udviklere, når de ikke længere har kunne få VB6 af Microsoft, så har det været mere naturligt at skifte til VB.Net, da der er mange af de samme hjerneblødninger som man finder i VB6.
C# er et pænere sprog, men det er også meget anderledes hvis man har kodet i VB6. Mange af de gamle VB6 programmører har aldrig rigtigt lært at forstå programmeringssprog, under alle omstændigheder er mange af dem selvlærte og det giver altså nogle lidt underlige designmønstre, der egentligt passer bedre ind i VB, fremfor C#.
Og nej, jeg kan ikke li' VB. Det er nemt at udvikle i, det er nok også problemet, det kræver ikke helt nok baggrundsviden før at folk kan komme igang med at spytte kode ud.
Af små underligheder i VB.Net (v1.1), boolean operators er ikke short circuited (AndAlso og OrElse findes heldigvis), afrunding (Math.Round) er banker's rounding (HVORFOR?) og så skal man være lidt forsigtig med variabler i loops, .Net kan godt finde på at instantiere dem lidt på forhånd, og også gerne med værdien fra en tidligere interation af loopet.
C# er et pænere sprog, men det er også meget anderledes hvis man har kodet i VB6. Mange af de gamle VB6 programmører har aldrig rigtigt lært at forstå programmeringssprog, under alle omstændigheder er mange af dem selvlærte og det giver altså nogle lidt underlige designmønstre, der egentligt passer bedre ind i VB, fremfor C#.
Og nej, jeg kan ikke li' VB. Det er nemt at udvikle i, det er nok også problemet, det kræver ikke helt nok baggrundsviden før at folk kan komme igang med at spytte kode ud.
Af små underligheder i VB.Net (v1.1), boolean operators er ikke short circuited (AndAlso og OrElse findes heldigvis), afrunding (Math.Round) er banker's rounding (HVORFOR?) og så skal man være lidt forsigtig med variabler i loops, .Net kan godt finde på at instantiere dem lidt på forhånd, og også gerne med værdien fra en tidligere interation af loopet.
#20:
Noget specielt du bygger den påstand på? Der er ingen der siger du ikke kan finde en bug i 1.1 understøttelsen, men den er svær at rette hvis du ikke konkretiserer.
#22: Hvornår har du sidst prøvet? Og kunne du også være lidt mere konkret, er det web-relateret eller ..?
Ligesom med deres .NET 2.0 support. Hvorfor går man igang med at understøtte 2.0 når ens 1.1 praktisk talt ikke virker???
Noget specielt du bygger den påstand på? Der er ingen der siger du ikke kan finde en bug i 1.1 understøttelsen, men den er svær at rette hvis du ikke konkretiserer.
#22: Hvornår har du sidst prøvet? Og kunne du også være lidt mere konkret, er det web-relateret eller ..?
#25
Det er jo en smagssag. Syntax'en er bare noget man skal vende sig til. Har selv været fuldtids java udvikler, og koder i dag rent i VB.net, uden problemer.
Er det du forsøger på at sige, at jo sværere et sprog er, jo bedre programmer kommer der ud af det ?
At du ikke kan lide det er helt okay, men om folk kan programmere eller ej, gør ikke den store forskel. Der er også lavet stakkevis af programmer af folk uden forstand på det i php, perl, og andre mere ikke begynder sprog.
Ret nemt hvorfor ikke ?
Nogle har vedtaget at sådanne er det, hvis du forventer noget andet viser det at du nok ikke har 'rigtigt lært at forstå programmeringssprog' for at citere dig selv. Læs spec's inden du koder så ville du vide at det var sådanne.
Der står ligefrem :
The behavior of this method follows IEEE Standard 754, section 4. This kind of rounding is sometimes called rounding to nearest, or banker's rounding.
Forresten gælder det også C#, J# osv.
Som du tydeligt kan se er det sågar en IEEE standard de følger.
Læs selv her:
http://msdn2.microsoft.com/en-us/library/wyk4d9cy....
Et eksempel tak.
C# er et pænere sprog,
Det er jo en smagssag. Syntax'en er bare noget man skal vende sig til. Har selv været fuldtids java udvikler, og koder i dag rent i VB.net, uden problemer.
Og nej, jeg kan ikke li' VB. Det er nemt at udvikle i, det er nok også problemet, det kræver ikke helt nok baggrundsviden før at folk kan komme igang med at spytte kode ud.
Er det du forsøger på at sige, at jo sværere et sprog er, jo bedre programmer kommer der ud af det ?
At du ikke kan lide det er helt okay, men om folk kan programmere eller ej, gør ikke den store forskel. Der er også lavet stakkevis af programmer af folk uden forstand på det i php, perl, og andre mere ikke begynder sprog.
afrunding (Math.Round) er banker's rounding (HVORFOR)
Ret nemt hvorfor ikke ?
Nogle har vedtaget at sådanne er det, hvis du forventer noget andet viser det at du nok ikke har 'rigtigt lært at forstå programmeringssprog' for at citere dig selv. Læs spec's inden du koder så ville du vide at det var sådanne.
Der står ligefrem :
The behavior of this method follows IEEE Standard 754, section 4. This kind of rounding is sometimes called rounding to nearest, or banker's rounding.
Forresten gælder det også C#, J# osv.
Som du tydeligt kan se er det sågar en IEEE standard de følger.
Læs selv her:
http://msdn2.microsoft.com/en-us/library/wyk4d9cy....
og så skal man være lidt forsigtig med variabler i loops, .Net kan godt finde på at instantiere dem lidt på forhånd, og også gerne med værdien fra en tidligere interation af loopet.
Et eksempel tak.
#26 Meget i programmeringssprog er naturligvis en smagssag. Mit problem er at med Visual Studio og VB.Net, behover du ikke rigtigt at forstå hvad du laver, for at kunne udvikle software. Det har været min oplevelse at folk uden nogen form for undervisning i software udvikling typsik laver meget disfunktionel kode.
Mit Math.Round eksempel er ikke andet end eksempel på at VB, og tilsyneladende også C# og J# opfører sig på uventede måder i mange tilfælde. Jeg siger ikke at det ikke er en standard, det er bare ikke hvad de fleste ville forvente.
Eksempel på dumme loop. Lav et hvilket somhelst loop, der looper mere end en gang, opret en variabel, et eller andet objekt, ikke primitiv datatype. Tildel variablen en værdi. Ved næste iteration vil du ved hjælp af debuggeren se at variabel instatieres lidt tidligere end forventet og har værdien fra sidste iteration.
Fair nok, man skal selvfølgelig heller ikke have variabler der bare bare bliver instatieres uden værdi, så problemet er let løs, men igen, meget uventet opførsel.
Man kan lave grim/dårlig kode i alle sprog, jeg ser det bare oftere i VB (og PHP når du nu selv nævner det), begge sprog har den fordel at de er meget lette at gå til.
Mit Math.Round eksempel er ikke andet end eksempel på at VB, og tilsyneladende også C# og J# opfører sig på uventede måder i mange tilfælde. Jeg siger ikke at det ikke er en standard, det er bare ikke hvad de fleste ville forvente.
Eksempel på dumme loop. Lav et hvilket somhelst loop, der looper mere end en gang, opret en variabel, et eller andet objekt, ikke primitiv datatype. Tildel variablen en værdi. Ved næste iteration vil du ved hjælp af debuggeren se at variabel instatieres lidt tidligere end forventet og har værdien fra sidste iteration.
Fair nok, man skal selvfølgelig heller ikke have variabler der bare bare bliver instatieres uden værdi, så problemet er let løs, men igen, meget uventet opførsel.
Man kan lave grim/dårlig kode i alle sprog, jeg ser det bare oftere i VB (og PHP når du nu selv nævner det), begge sprog har den fordel at de er meget lette at gå til.
#28
Det er da bestemt ikke uventet, det er måske ikke som de sprog du ellers kender, men Math.Round opfører sig præcist som forventet for du har vel læst specifikationerne til metoderne ikke ?
Eller i det mindste gjort det med det samme du opdagede tingene ikke var helt som du troede, og så er problemet jo løst for nu ved du det.
At bare tro det er som det er andre steder, er bestemt ikke altid en smart indgangsvinkel.
Kode tak.
Mener du den deklareres og instantieres inde i loop'en ?
Så er du i samme scope og derfor er det jo helt fint, compileren kan jo se den skal lave den igen, og kan derfor nøjes med at gøre det engang. Hvad er der uventet ved det ?
Helt enig de er nemme at gå til.
Men synes du virkeligt sprogene skal være så besværlige og værktøjerne så umulige at gå til, at kun folk med en phd i datalogi kan bruge dem ?
Mit Math.Round eksempel er ikke andet end eksempel på at VB, og tilsyneladende også C# og J# opfører sig på uventede måder i mange tilfælde.
Det er da bestemt ikke uventet, det er måske ikke som de sprog du ellers kender, men Math.Round opfører sig præcist som forventet for du har vel læst specifikationerne til metoderne ikke ?
Eller i det mindste gjort det med det samme du opdagede tingene ikke var helt som du troede, og så er problemet jo løst for nu ved du det.
At bare tro det er som det er andre steder, er bestemt ikke altid en smart indgangsvinkel.
Eksempel på dumme loop.
Kode tak.
Mener du den deklareres og instantieres inde i loop'en ?
Så er du i samme scope og derfor er det jo helt fint, compileren kan jo se den skal lave den igen, og kan derfor nøjes med at gøre det engang. Hvad er der uventet ved det ?
Man kan lave grim/dårlig kode i alle sprog, jeg ser det bare oftere i VB (og PHP når du nu selv nævner det), begge sprog har den fordel at de er meget lette at gå til.
Helt enig de er nemme at gå til.
Men synes du virkeligt sprogene skal være så besværlige og værktøjerne så umulige at gå til, at kun folk med en phd i datalogi kan bruge dem ?
#19
Nej. VS brugerner har haft VB.NET compiler i 6-7 år. Det nye
er at Mono brugerne får en (god) VB.NET compiler.
Og den umiddelbare pointe er. at nu kan udviklere som kun bruger
Linux også compile VB.NET kode.
Iøvrigt holder "lige meget hvilken platform man bruger, så længe den understøtter .NET frameworket" ikke helt vand. Mono og MS .NET
er ikke 100% kompatible snarere et eller andet sted mellem 90% og 98%.
Derfor kunne selv dem som bruger Windows og VS være interesseret
i at comoile deres VB.NET kode med Mono for at se om de brugte
klasser og metoder i det mindste eksisterer i Mono.
Nej. VS brugerner har haft VB.NET compiler i 6-7 år. Det nye
er at Mono brugerne får en (god) VB.NET compiler.
Og den umiddelbare pointe er. at nu kan udviklere som kun bruger
Linux også compile VB.NET kode.
Iøvrigt holder "lige meget hvilken platform man bruger, så længe den understøtter .NET frameworket" ikke helt vand. Mono og MS .NET
er ikke 100% kompatible snarere et eller andet sted mellem 90% og 98%.
Derfor kunne selv dem som bruger Windows og VS være interesseret
i at comoile deres VB.NET kode med Mono for at se om de brugte
klasser og metoder i det mindste eksisterer i Mono.
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