mboost-dp1
Microsoft Corporation
Det hedder C# og ikke bare # ;).
Tror det bliver epic fail. Startede selv med at programmere i VB6, og det opfordrer virkeligt mere end noget andet sprog jeg kender til at skrive masser af slamkode.
Ligemeget hvor god en konverteringsalgoritme de får skrevet vil det ikke kunne rette op på alle de ineffektive og rodede programmer der er skrevet, så resultatet vil være en masse C#/VB.Net programmer der trænger til at blive skrevet om...
Tror jeg ;).
Tror det bliver epic fail. Startede selv med at programmere i VB6, og det opfordrer virkeligt mere end noget andet sprog jeg kender til at skrive masser af slamkode.
Ligemeget hvor god en konverteringsalgoritme de får skrevet vil det ikke kunne rette op på alle de ineffektive og rodede programmer der er skrevet, så resultatet vil være en masse C#/VB.Net programmer der trænger til at blive skrevet om...
Tror jeg ;).
Måske er det også en god lejlighed for de der netop har programmer med vb-kode, at få kigget den gamle visual basic-kode igennem, og ved den MANUELLE konvertering til C#, indføre noget mere smart og smidigt objektorienteret.
Alle de sprogkonverteringsprogrammer jeg har set i tidens løb, har trashet så meget at man bruger mere tid på at optimere og korrigere, end hvis man manuelt omskrev hele dynen. Så snart det bliver mere avanceret end deklarering, "if" og "for" og lignende, sviner de koden mere end selv de ældre versioner af Frontpage gjorde med html.
Alle de sprogkonverteringsprogrammer jeg har set i tidens løb, har trashet så meget at man bruger mere tid på at optimere og korrigere, end hvis man manuelt omskrev hele dynen. Så snart det bliver mere avanceret end deklarering, "if" og "for" og lignende, sviner de koden mere end selv de ældre versioner af Frontpage gjorde med html.
#1 og #3, kom lige tilbage til virkeligheden. Hvis virksomheder øjner en chance for at kunne anvende deres gamle kode som virker perfekt, fordi den er blevet tweaket gennem mange år, så vil de helt klart vælge det frem for at skulle investere mange timer og penge i at udvikle de ting som de allerede har.
R.I.P VB6.
Har nu aldrig brud mig meget om VB, har dog været nødsaget til at lave små macroer og andre ting i dette sprog.
Men jeg giver ikke folk helt ret i at det er sproget der giver slam kode det er den person AKA programmøren som laver slam kode.
Kan i dag 7 programmerings sprog og jeg har set når der er lavet slamkode, det meste slamkode skyldes som regle mangle på forståelse om at man skal lave dokumentationen om det program man vil lave, før man laver koden.
Mange sætter sig ned og laver koden havner i et problem som kunne være undgået hvis man har lavet dokumentationen først og der efter laver en eller anden work around som for det meste både er grim og en værer gang slamkode med masser af leaks.
en af dem jeg ser meget kan være...
EKS statestik beregning.
float fo(int Array[])
{
float Statestik = 0.0;
int Count = Array.Length;
for (int i = 0; i < Count; i++)
{
int sum;
sum += Array[i]
Statestik += Sum / Count;
}
return Statestik.
}
denne funktion kalder man så xx 1000 gange med et array størrelse på xxx hvilket resultere i at int sum bliver oprettet mange mange mange gange incl alle andre variabler i funktionen
Og nu sidder der sikkert nogle kloge hoved og siger jamen det tager Garabage collectoren sig af.
Svar:
"Ja det gør den, dog skal man lige huske den køre ikke lige så snart du er hoppet ud af funktionen nej der går et godt stykke tid, men imellem tiden står funktionen og arkumulere hukommelse som en 10 knægt med et BMI på 90 i en slikbutik."
Selv hvis du kalder GC.Collect(); vil der gå et godt stykke tid.
Har nu aldrig brud mig meget om VB, har dog været nødsaget til at lave små macroer og andre ting i dette sprog.
Men jeg giver ikke folk helt ret i at det er sproget der giver slam kode det er den person AKA programmøren som laver slam kode.
Kan i dag 7 programmerings sprog og jeg har set når der er lavet slamkode, det meste slamkode skyldes som regle mangle på forståelse om at man skal lave dokumentationen om det program man vil lave, før man laver koden.
Mange sætter sig ned og laver koden havner i et problem som kunne være undgået hvis man har lavet dokumentationen først og der efter laver en eller anden work around som for det meste både er grim og en værer gang slamkode med masser af leaks.
en af dem jeg ser meget kan være...
EKS statestik beregning.
float fo(int Array[])
{
float Statestik = 0.0;
int Count = Array.Length;
for (int i = 0; i < Count; i++)
{
int sum;
sum += Array[i]
Statestik += Sum / Count;
}
return Statestik.
}
denne funktion kalder man så xx 1000 gange med et array størrelse på xxx hvilket resultere i at int sum bliver oprettet mange mange mange gange incl alle andre variabler i funktionen
Og nu sidder der sikkert nogle kloge hoved og siger jamen det tager Garabage collectoren sig af.
Svar:
"Ja det gør den, dog skal man lige huske den køre ikke lige så snart du er hoppet ud af funktionen nej der går et godt stykke tid, men imellem tiden står funktionen og arkumulere hukommelse som en 10 knægt med et BMI på 90 i en slikbutik."
Selv hvis du kalder GC.Collect(); vil der gå et godt stykke tid.
#9 Det er ikke et særligt godt eksempel. Udover der er temmelig mange syntax fejl i, så er garbage collectoren slet ikke involveret i den funktion. "sum" er en value type og resultatet af den lagres som en lokal variabel. Det kan man se hvis man kigger på IL koden der genereres.
Et bedre eksempel ville være:
Her bliver der rent faktisk oprettet et nyt string objekt for hver iteration og det objekt ryger til skrald.
I øvrigt giver det ikke nogen fordel at gemme længden af array'et som en lokal variabel, da det ikke er nogen property.
private float fo(int[] Array)
{
float Statestik = 0.0f;
int Count = Array.Length;
for (int i = 0; i < Count; i++)
{
int sum = 0;
sum += Array[i];
Statestik += sum / Count;
}
return Statestik;
}
Et bedre eksempel ville være:
private string Concat(string[] strings)
{
string result = String.Empty;
for (int i = 0; i < strings.Length; i++)
result += strings[i];
return result;
}
Her bliver der rent faktisk oprettet et nyt string objekt for hver iteration og det objekt ryger til skrald.
I øvrigt giver det ikke nogen fordel at gemme længden af array'et som en lokal variabel, da det ikke er nogen property.
for the love of god just upgrade to C#
ej, jeg kan bare personligt ikke lide VB og dens (mangel af) struktur.
men man må håbe den kan konvertere det meste og så på pege hvor den måske ikke har gjort det så godt.
#8:
ja for Cobol er jo sådan et moderne og fremtidsikret sprog... :p
ej, jeg kan bare personligt ikke lide VB og dens (mangel af) struktur.
men man må håbe den kan konvertere det meste og så på pege hvor den måske ikke har gjort det så godt.
#8:
ja for Cobol er jo sådan et moderne og fremtidsikret sprog... :p
Jeg har svært ved at se hvorfor firmaer lige pludselig skulle konvertere alle deres VB6-projekter nu. Visual Studio fungerer stadigvæk om 5 år. Microsoft har næppe tænkt sig at udsende en "KILL VB6 AND VS6"-virus.
Derudover så har der også altid eksistereret en VB6->VB.NET-konverter, som er indbygget VB.NET-IDE'en. Og ligesom der nævnes i artiklen, så kan denne også konvertere ca. 90-95%. Hvorfor skulle man købe en dyr konverter hos Artinsoft, der kan det samme (eller måske er lidt bedre)?
Derudover, så har jeg efterhånden konverteret mange VB6 og ASP-projekter og ved store projekter er det oftest hurtigere med en fuld manuel genopbygning. (Man kan godt konvertere store VB-programmer, men det færdige resultat bliver et produkt der er dårligere end det oprindelige og derudover er det stoppet med slam-kode.) Hvis man ikke har mod på en manuel genopbygning, så behold VB-programmet. (VB fungerer ligeså "godt" nu, som for 10 år siden.)
Det ser forøvrigt heller ikke ud til, at der skulle være problemer med VB6 og Vista o.s.v. (Men vi har nu heller ikke så mange VB6-programmer tilbage.)
PS. Og som afslutningsbemærkning, så overvejer jeg faktisk selv at udvikle en "KILL VB6"-virus. Hehe! DIE FILTHY VB! ... Tror faktisk at jeg vil skrive den i VB6. Oh, the irony!
Derudover så har der også altid eksistereret en VB6->VB.NET-konverter, som er indbygget VB.NET-IDE'en. Og ligesom der nævnes i artiklen, så kan denne også konvertere ca. 90-95%. Hvorfor skulle man købe en dyr konverter hos Artinsoft, der kan det samme (eller måske er lidt bedre)?
Derudover, så har jeg efterhånden konverteret mange VB6 og ASP-projekter og ved store projekter er det oftest hurtigere med en fuld manuel genopbygning. (Man kan godt konvertere store VB-programmer, men det færdige resultat bliver et produkt der er dårligere end det oprindelige og derudover er det stoppet med slam-kode.) Hvis man ikke har mod på en manuel genopbygning, så behold VB-programmet. (VB fungerer ligeså "godt" nu, som for 10 år siden.)
Det ser forøvrigt heller ikke ud til, at der skulle være problemer med VB6 og Vista o.s.v. (Men vi har nu heller ikke så mange VB6-programmer tilbage.)
PS. Og som afslutningsbemærkning, så overvejer jeg faktisk selv at udvikle en "KILL VB6"-virus. Hehe! DIE FILTHY VB! ... Tror faktisk at jeg vil skrive den i VB6. Oh, the irony!
#9+#10
I er nogle dejlige nørder - luv's U
nå tilbage til topic.
altså vores firma har da stadig en DOS-maskine kørende. Hver gang en IT-mand kommer forbi slår han cola'ens tegn (i mangel af kors/halvmåne) og kræver straks den slukket...indtil han opdager den ikke er på netværket. Så plejer de at bliver helt nostagislke (staveplade)
morale:
gamle ting der fungerer vil STADIG køre videre. Der skal nogle store besparelser til før sådan nogen som CITI-bank vil skifte noget fungerende ud med noget nyt!
.M
I er nogle dejlige nørder - luv's U
nå tilbage til topic.
altså vores firma har da stadig en DOS-maskine kørende. Hver gang en IT-mand kommer forbi slår han cola'ens tegn (i mangel af kors/halvmåne) og kræver straks den slukket...indtil han opdager den ikke er på netværket. Så plejer de at bliver helt nostagislke (staveplade)
morale:
gamle ting der fungerer vil STADIG køre videre. Der skal nogle store besparelser til før sådan nogen som CITI-bank vil skifte noget fungerende ud med noget nyt!
.M
#15:
Og så længe at man holder til den filosofi er det blot et spørgsmål om tid før vi får år 2000-problematikken igen; Eller 2038-problemet, for UNIX-systemer.
gamle ting der fungerer vil STADIG køre videre. Der skal nogle store besparelser til før sådan nogen som CITI-bank vil skifte noget fungerende ud med noget nyt!
Og så længe at man holder til den filosofi er det blot et spørgsmål om tid før vi får år 2000-problematikken igen; Eller 2038-problemet, for UNIX-systemer.
illishar (14) skrev:Hvorfor skulle man købe en dyr konverter hos Artinsoft, der kan det samme (eller måske er lidt bedre)?
Den indbyggede converter i VS IDE'et ER lavet af Artinsoft ;)
crashoverride (9) skrev:
Svar:
"Ja det gør den, dog skal man lige huske den køre ikke lige så snart du er hoppet ud af funktionen nej der går et godt stykke tid, men imellem tiden står funktionen og arkumulere hukommelse som en 10 knægt med et BMI på 90 i en slikbutik."
Selv hvis du kalder GC.Collect(); vil der gå et godt stykke tid.
Du får ikke ekstra præmie for at have ubrugt memory på systemet. Hvis der er mangel på memory så kører GC. Hvis der ikke er mange, så er der ingen grund til at spild etid på det.
#21 Ja det er rigtigt at Length er en property. Men MSIL understøtter at hente længder af arrays natively (altså direkte med en opcode). Så compileren genererer ikke kode til at hente property'en, som den normalvis vil gøre - altså via. et funktions kald til get_<Propertynavn>.
Det er det der får mig til at ikke at betegne den som en property.
Det er det der får mig til at ikke at betegne den som en property.
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