[alg] Slechtste programmeervoorbeelden deel 4

[PrisonerOfPain]

.oisyn schreef op vrijdag 29 oktober 2010 @ 17:13:
[...]


Oh, dat stukje over strikte mode had ik even gemist. Moet jij trouwens niet wat compile errors fixen?

Hoezo, het compiled toch gewoon?

[Avalaxy]

Het past ook wel onder een 'slecht programmeervoorbeeld' dat ik, doordat ik Java eens een update wilde geven naar de nieuwe SDK, ruim 5 uur lang bezig ben geweest om het weer werkend te krijgen (complete java + eclipse + java 3D reïnstall meerdere keren gedaan, heel veel lopen proberen met de build path, met environment variables, etc.).

Jaja, "don't fix what ain't broken" gaat op, en ja ik ben een statsgeiler die altijd de nieuwste versie wilt

[Spockz]

Verwijderd schreef op vrijdag 29 oktober 2010 @ 17:11:

C++:

    void Player::initActuators()
    {
        for(std::map<int, std::map<int, int> >::iterator fIt = mConfiguration.mPositionMap.begin(); fIt!=mConfiguration.mPositionMap.end();fIt++)
        {
            CANDFrame fRame;
            fRame.setBMI(can::bmi::NodeInit);
            fRame.setEMI((*fIt).first);
            if((*(*fIt).second.begin()).first==1)
            {
                fRame.setLength(2);
                fRame.body()[1] = 8 >> (*(*fIt).second.begin()).second;
                fRame.body()[0] = (*(*fIt).second.begin()).second;
            }else if((*(*fIt).second.begin()).first==2)
            {
                fRame.setLength(4);
                fRame.body()[0] = 24 >> (*(*fIt).second.begin()).second;
                fRame.body()[1] = 16 >> (*(*fIt).second.begin()).second;
                fRame.body()[2] = 8 >> (*(*fIt).second.begin()).second;
                fRame.body()[3] = (*(*fIt).second.begin()).second;
            }else if((*(*fIt).second.begin()).first==3)
            {
                fRame.setLength(2);
                fRame.body()[0] = 8 >> (*(*fIt).second.begin()).second;
                fRame.body()[1] = (*(*fIt).second.begin()).second;
            }
            
            mResources.getResource(mConfiguration.mCanId)->getConnection()->async_write(fRame.getLength(),fRame.data());

        }

    }

Vind het stukje waar mijn teamgenoten verzuimd hebben C++ te leren.

Zozo, zit je hier nou zomaar onze top-secret code te posten? Ik moet zeggen dat ik zelf deze code nooit gezien heb. Maar dat hele project was sowieso al gedoemd om te falen.

[Verwijderd]

De grootste WTF was inderdaad hoe het project werd aangestuurd.

[Verwijderd]

Boeboe schreef op woensdag 06 oktober 2010 @ 12:02:
kwam net een bizar stukje sql tegen (fictieve velden):

SQL:

SELECT veld1, veld2, GETDATE() as Expr1 FROM tabel
ORDER BY Expr1

wut

Je kan toch, als je een query moet doen, gelijk ook een andere SQL functie als kolom gebruiken die je toch nodig hebt. Beter dan 2 queries. (ok, dit kon ook in native php, met een extra handeling dan wel..)
Scheelt je programmeertijd en de computer rekentijd.. Ok.. in dit voorbeeld zijn er wel meerdere rows, maar ik weet niet of dat voor mysql uitmaakt qua processortijd.

[ Voor 3% gewijzigd door Verwijderd op 31-10-2010 12:32 ]

[Ventieldopje]

Op de man spelen word niet gewaardeerd

[ Voor 78% gewijzigd door Woy op 31-10-2010 13:45 ]

[RikTW]

Verwijderd schreef op zondag 31 oktober 2010 @ 12:31:
[...]

Je kan toch, als je een query moet doen, gelijk ook een andere SQL functie als kolom gebruiken die je toch nodig hebt. Beter dan 2 queries. (ok, dit kon ook in native php, met een extra handeling dan wel..)
Scheelt je programmeertijd en de computer rekentijd.. Ok.. in dit voorbeeld zijn er wel meerdere rows, maar ik weet niet of dat voor mysql uitmaakt qua processortijd.

Het heeft alleen niet heel veel zin om hierop te sorteren

[PiepPiep]

Misschien dat je als de query voor 12 uur 's nachts begint en na 12 uur 's nachts eindigt verschillende datum waarden terug.
Dan weet je op een omslachtige manier dat het 12 uur 's nachts was

[CodeCaster]

PiepPiep schreef op maandag 01 november 2010 @ 09:07:
Misschien dat je als de query voor 12 uur 's nachts begint en na 12 uur 's nachts eindigt verschillende datum waarden terug.
Dan weet je op een omslachtige manier dat het 12 uur 's nachts was

Dat is dus niet zo, er is weliswaar een bug geweest die dat gedrag vertoonde, maar het verwachte gedrag is dat GETDATE() in één query steeds dezelfde waarde retourneert, ongeacht de uitvoertijd van die query.

[Janoz]

@PiepPiep (& twicejr)

Ookal zou GetDate bij elke aanroep een andere datum terug geven (omdat het bv in ms is), probeer dan maar eens te omschrijven wat het nut is van het sorteren op die expressie. Kleine hulpvraag: Welke datum wordt bij welk record gezet?

[Styxxy]

Ik ben net een mooie tegen gekomen in PHP...

PHP:

<?php

function worteltrekken($getal) 
{ 
    $resultaat = $getal / $getal; 
    return $resultaat; 
}

[ Voor 16% gewijzigd door Styxxy op 01-11-2010 22:02 ]

[Freeaqingme]

Zo blijkt maar weer dat hogere wiskunde niet voor normale stervelingen is weggelegd

[Onbekend]

Oh, ze hebben de functie een verkeerde naam gegeven.

[ShitHappens]

En ik calc.exe opstarten om te zien wat het doet
Maar goed het kan dus korter

PHP:

return sqrt($getal);

Weer wat geleerd

[Verwijderd]

Hmm, da's niet meer dan een omslachtige manier om "1" te returnen?

[Verwijderd]

mooie manier om te controleren of datstructuur $getal een / operator heeft

[Lye]

Verwijderd schreef op dinsdag 02 november 2010 @ 00:39:
mooie manier om te controleren of datstructuur $getal een / operator heeft

In principe, zei het niet dat als $getal geen int/float is, dit naar een int gecast wordt en vaak 0 op zal leveren.

Kan dus ook zijn dat het een mooie Division by zero warning oplevert in plaats van 1, heeft deze implementatie toch nog nut

[.oisyn]

Duh, als x² hetzelfde is als x*x, dan zal √x wel hetzelfde zijn als x/x. Toch?

[Matis]

.oisyn schreef op dinsdag 02 november 2010 @ 00:48:
Duh, als x² hetzelfde is als x*x, dan zal √x wel hetzelfde zijn als x/x. Toch?

Mijn vriendin (HAVO C&M ) vond worteltrekken ook altijd heel lastig. Totdat ik haar vertelde dat het (vierkants)worteltrekken ook geschreven kon worden als x^0.5.
Toen begreep ze ook in een keer waarom worteltrekken van een kwadraat altijd het grondtal oplevert.
Immers x^0.5 ^ ² = x^{(0.5 * 2)} = x¹ = x
Sindsdien gebruikt ze ook geen wortelteken meer, maar de ^0.5-notatie.

Ook wanneer er meer dan een tweedenmachtswortel getrokken moet worden, kan ze deze notatie veel gemakkelijker toepassen (in haar ogen althans) dan met het wortelteken.

[!null]

Matis schreef op dinsdag 02 november 2010 @ 08:04:
Immers x^0.5 * x² = x^{(0.5 * 2)} = x¹ = x

Ik ben het eens met je verhaal, maar deze formule klopt toch niet?
Volgens mij kan je x^0.5 * x² niet vertalen in x^{(0.5 * 2)}
Tenminste, als ik beide uitreken met een voorbeeld input komt er toch twee verschillende dingen uit.
Maak ik een wiiskundig foutje?

Edit: wanneer je twee maal X hebt staan met verschillende machtsgetallen en je wilt deze samenvoegen moet je deze machtsgetallen optellen en niet vermenigvuldigen.
Dus x^0.5 * x² wordt x^{(0.5 + 2)}
en dat is natuurlijk niet gelijk aan x¹

[ Voor 37% gewijzigd door !null op 02-11-2010 09:02 ]

[Matis]

!null schreef op dinsdag 02 november 2010 @ 08:55:
[...]


Ik ben het eens met je verhaal, maar deze formule klopt toch niet?
Volgens mij kan je x^0.5 * x² niet vertalen in x^{(0.5 * 2)}
Tenminste, als ik beide uitreken met een voorbeeld input komt er toch twee verschillende dingen uit.
Maak ik een wiiskundig foutje?

Edit: wanneer je twee maal X hebt staan met verschillende machtsgetallen en je wilt deze samenvoegen moet je deze machtsgetallen optellen en niet vermenigvuldigen.
Dus x^0.5 * x² wordt x^{(0.5 + 2)}
en dat is natuurlijk niet gelijk aan x¹

Hmm, ja je hebt gelijk, het is natuurlijk tot de macht tot de macht, waarmee je dus de machten mag vermenigvuldigen Probleem is dat de UBB-code geen geneste sups toestaat.

Maar je hebt natuurlijk gelijk.

Edit; ik heb het maar aangepast. Was natuurlijk wel een slecht programmeervoorbeeld

[ Voor 9% gewijzigd door Matis op 02-11-2010 09:08 ]

[kunnen]

(2^3)^2=(2^3)*(2^3)=(2*2*2)*(2*2*2)=2*2*2*2*2*2=2^6

[HuHu]

!null schreef op dinsdag 02 november 2010 @ 08:55:
[...]


Ik ben het eens met je verhaal, maar deze formule klopt toch niet?
Volgens mij kan je x^0.5 * x² niet vertalen in x^{(0.5 * 2)}
Tenminste, als ik beide uitreken met een voorbeeld input komt er toch twee verschillende dingen uit.
Maak ik een wiiskundig foutje?

Edit: wanneer je twee maal X hebt staan met verschillende machtsgetallen en je wilt deze samenvoegen moet je deze machtsgetallen optellen en niet vermenigvuldigen.
Dus x^0.5 * x² wordt x^{(0.5 + 2)}
en dat is natuurlijk niet gelijk aan x¹

Klopt, het is ook fout. Vul voor x maar eens 9 in: 9^0.5 * 9² = 3 * 81 = 243. Het volgende is wel correct: (x^a)^b = x^(a*b). Neem je voor a en b respectievelijk 2 en 0.5, dan krijg je (x²)^0.5 = √(x²) = x¹ = x

[kenneth]

Zo, en nu zijn de [sup]'s op voor vandaag

[PiepPiep]

C:

#define     CASE_LOWER_CASE  case  'a': case  'b': case  'c': case  'd': case  'e': case  'f': case  'g': case  'h': case  'i': case  'j': case  'k': case  'l': case  'm': case  'n': case  'o': case  'p': case  'q': case  'r': case  's': case  't': case  'u': case  'v': case  'w': case  'x': case  'y': case  'z':
#define     CASE_UPPER_CASE  case  'A': case  'B': case  'C': case  'D': case  'E': case  'F': case  'G': case  'H': case  'I': case  'J': case  'K': case  'L': case  'M': case  'N': case  'O': case  'P': case  'Q': case  'R': case  'S': case  'T': case  'U': case  'V': case  'W': case  'X': case  'Y': case  'Z':
#define     CASE_SPECIAL_CASE  case  '_': case  '\\': case  '.': case  '-':
#define     CASE_NUMBER      case  '0': case  '1': case  '2': case  '3': case  '4': case  '5': case  '6': case  '7': case  '8': case  '9':
#define     CASE_SPACE       case  9:   case  10:  case  13:  case  ' ':
#define     CASE_ENTITY_CHAR case  '_': case  '-':

Bron, software geschreven door een instituut dat nogal technisch hoog aangeschreven staat.

[Davio]

PiepPiep schreef op dinsdag 02 november 2010 @ 11:48:

C:

#define     CASE_LOWER_CASE  case  'a': case  'b': case  'c': case  'd': case  'e': case  'f': case  'g': case  'h': case  'i': case  'j': case  'k': case  'l': case  'm': case  'n': case  'o': case  'p': case  'q': case  'r': case  's': case  't': case  'u': case  'v': case  'w': case  'x': case  'y': case  'z':
#define     CASE_UPPER_CASE  case  'A': case  'B': case  'C': case  'D': case  'E': case  'F': case  'G': case  'H': case  'I': case  'J': case  'K': case  'L': case  'M': case  'N': case  'O': case  'P': case  'Q': case  'R': case  'S': case  'T': case  'U': case  'V': case  'W': case  'X': case  'Y': case  'Z':
#define     CASE_SPECIAL_CASE  case  '_': case  '\\': case  '.': case  '-':
#define     CASE_NUMBER      case  '0': case  '1': case  '2': case  '3': case  '4': case  '5': case  '6': case  '7': case  '8': case  '9':
#define     CASE_SPACE       case  9:   case  10:  case  13:  case  ' ':
#define     CASE_ENTITY_CHAR case  '_': case  '-':

Bron, software geschreven door een instituut dat nogal technisch hoog aangeschreven staat.

En dan worden Form Feeds (ASCII 12) niet eens herkend.

[.oisyn]

Wie gebruikt er nou form feeds

[kenneth]

EN WIE GEBRUIKT ER NOU LOWER CASE?

[Janoz]

Diacrieten zijn ook overrated.

[.oisyn]

Hey niet gaan schelden he!

[Verwijderd]

Bob schreef op woensdag 27 oktober 2010 @ 16:14:
Voor de volledigheid, een scoped lock gebruik je zo:

C++:

{
  boost::mutex::scoped_lock instance(mutex);
}

nog bedankt, besef me nu pas dat ik em zelf ook wel eens fout doe (zo'n 'even niet opletten == een avond debuggen' foutje )
die debugavond heb je me iig prematuur bespaard

[Matis]

Wut, ik zit net even mijn CSS te checken op W3C, komt hij met de melding:

131 #logo a, #logo a:link, #logo a:hover Property font-smooth doesn't exist in CSS level 2.1 but exists in : always always

Ik weet dat font-smooth niet werkt in CSS 2, maar vooral dat laatste stukje vind ik erg vreemd; Het bestaat niet in CSS 2.1, maar bestaat wel in elke versie oid

[Verwijderd]

Dat had ik ook met de selector `li + li::before`. Ik kreeg "but exists in : 0.5 0.5" ofzo. Kennelijk komen de waarden van een rule daar te staan, en hoort de standaardnaam vóór de dubbele punt te komen (vandaar de spatie). Echter, die feature werkt dus niet correct (mijn code was namelijk correct in css3).

[ Voor 16% gewijzigd door Verwijderd op 02-11-2010 23:01 ]

[StephanVierkant]

Het kan aan mij liggen, maar is dit ook niet een erg gekke manier van een foreach-loop?

PHP:

for($i=0;$i<count($header);$i++)
{
    $this->Cell($w[$i],5,$header[$i],1,0,'C',1);
}

[Matis]

Niet per definitie. Als je de index wilt weten, dan is dit een inzichtelijke manier om dat te bereiken.

Je had ook met een foreach-loopje kunnen werken, maar dan moet je toch weer een counter bijhouden, die de index bepaalt.

0,02

[ Voor 3% gewijzigd door Matis op 03-11-2010 20:53 ]

[Webgnome]

Stephan4kant schreef op woensdag 03 november 2010 @ 20:51:
Het kan aan mij liggen, maar is dit ook niet een erg gekke manier van een foreach-loop?

PHP:

for($i=0;$i<count($header);$i++)
{
    $this->Cell($w[$i],5,$header[$i],1,0,'C',1);
}

Behalve dat je count($header) in een variabel zou kunnen zetten zie ik niets geks?

[YopY]

Foreach is eigenlijk een erg gekke manier van een for-loop, .

[RayNbow]

Matis schreef op woensdag 03 november 2010 @ 20:52:
Niet per definitie. Als je de index wilt weten, dan is dit een inzichtelijke manier om dat te bereiken.

Je had ook met een foreach-loopje kunnen werken, maar dan moet je toch weer een counter bijhouden, die de index bepaalt.

0,02

Tja, in het geval van PHP misschien wel. Maar in een taal zoals bijv. Python kun je het voorbeeld van Stephan4kant in "[alg] Slechtste programmeervoorbeelden d..." oplossen met een foreach+zip om gelijktijdig door header en w heen te wandelen.

[Sebazzz]

Webgnome schreef op woensdag 03 november 2010 @ 20:53:
[...]

Behalve dat je count($header) in een variabel zou kunnen zetten zie ik niets geks?

Dat wordt wel weggeoptimaliseerd door de runtime mag ik hopen ....

[ Voor 3% gewijzigd door Sebazzz op 03-11-2010 21:30 ]

[ValHallASW]

Sebazzz schreef op woensdag 03 november 2010 @ 21:30:
Dat wordt wel weggeoptimaliseerd door de runtime mag ik hopen ....

En wat als $header of $w gedurende de loop wordt aangepast?

[PrisonerOfPain]

Sebazzz schreef op woensdag 03 november 2010 @ 21:30:
[...]

Dat wordt wel weggeoptimaliseerd door de runtime mag ik hopen ....

Waarom ga je daar vanuit?

[Hillie]

YopY schreef op woensdag 03 november 2010 @ 20:55:
Foreach is eigenlijk een erg gekke manier van een for-loop, .

Ik tik vrij geregeld in e, object/aspect-georienteerde (hardware-)verificatietaal, die een relatief "natuurlijke" syntax heeft. Daar kun je 'for each' mooi toepassen in zowel generation constraints (voor random generator), als procedurele code. Leest erg prettig weg:

code:

my_method(my_list: list of uint) is {
   for each in my_list {
      //tralalala
   };
};

[alex3305]

Elke loop heeft z'n eigen functie en een foreach en for-loop behoren daar ook toe. Als je de index moet kennen voor een bepaald stuk code kun je beter een for-loop gebruiken, anders is meestal een foreach-loop handiger.

In PHP kun een for-loop beter gebruiken wanneer je met indexes als getallen wilt werken in een loop dan wanneer de lijst gevuld is met niet-incrementele getallen. Dan kun je eventueel nog een foreach-loop gebruiken met key en value.

Overigens vind ik dan weer de PHP array meer een dictionary is dan een echte array. Maargoed andere discussie denk ik .

[ Voor 12% gewijzigd door alex3305 op 03-11-2010 21:59 ]

[Patriot]

Hillie schreef op woensdag 03 november 2010 @ 21:56:
[...]


Ik tik vrij geregeld in e, object/aspect-georienteerde (hardware-)verificatietaal, die een relatief "natuurlijke" syntax heeft. Daar kun je 'for each' mooi toepassen in zowel generation constraints (voor random generator), als procedurele code. Leest erg prettig weg:

code:

my_method(my_list: list of uint) is {
   for each in my_list {
      //tralalala
   };
};

maar... hoe roep je dan aan wat er in die list zit?

EDIT: Overigens, het codevoorbeeld waar dit om gaat is natuurlijk heel logisch. Je gebruikt daar een for-loop omdat er met twee arrays wordt gewerkt. Je kunt dan wel één van de arrays in de foreach stoppen en met behulp van de keys daarvan de waarde van de andere array ophalen, maar dat vind ik niet even logisch.

[ Voor 22% gewijzigd door Patriot op 03-11-2010 22:03 ]

[CoolGamer]

PrisonerOfPain schreef op woensdag 03 november 2010 @ 21:56:
[...]
Waarom ga je daar vanuit?

Meeste verzamelingtypes houden hun grootte bij in een variabele. Een variabele returnen in een functie is nou niet bepaald significant zwaar. Dus al wordt het niet geoptimaliseerd, dan kost het nog steeds amper wat.

[PrisonerOfPain]

TheCoolGamer schreef op woensdag 03 november 2010 @ 22:00:
[...]

Meeste verzamelingtypes houden hun grootte bij in een variabele. Een variabele returnen in een functie is nou niet bepaald significant zwaar. Dus al wordt het niet geoptimaliseerd, dan kost het nog steeds amper wat.

Mijn punt dus precies; het word niet weggeoptimaliseerd het is in eerste instantie al niet inefficient.

[hostname]

Matis schreef op woensdag 03 november 2010 @ 20:52:
Niet per definitie. Als je de index wilt weten, dan is dit een inzichtelijke manier om dat te bereiken.

Je had ook met een foreach-loopje kunnen werken, maar dan moet je toch weer een counter bijhouden, die de index bepaalt.

0,02

PHP heeft ook een key-value foreach

PHP:

foreach($header as $i => $value) {
   $this->Cell($w[$i], 5, $value, 1, 0, 'C', 1);
}

Ik vind de originele code wel duidelijker.
Overigens ben ik nu wel benieuwd wat die 5, 1, 0, 'C' en 1 betekenen. Ik gok er zomaar op dat die nullen en enen booleans zijn die als integers zijn genoteerd.

Sebazzz schreef op woensdag 03 november 2010 @ 21:30:
[...]

Dat wordt wel weggeoptimaliseerd door de runtime mag ik hopen ....

In het geval van PHP niet. Zou ook niet kunnen, want je zou in de loop een volgend item uit de array kunnen verwijderen en dan heeft de count dus een andere waarde. Waarom je dat zou willen, geen idee, maar het kan wel.

[BBrunekreeft]

hostname schreef op donderdag 04 november 2010 @ 15:49:
[...]

PHP heeft ook een key-value foreach

PHP:

foreach($header as $i => $value) {
   $this->Cell($w[$i], 5, $value, 1, 0, 'C', 1);
}

Ik vind de originele code wel duidelijker.
Overigens ben ik nu wel benieuwd wat die 5, 1, 0, 'C' en 1 betekenen. Ik gok er zomaar op dat die nullen en enen booleans zijn die als integers zijn genoteerd.

Ziet er uit als iets van fpdf: http://www.fpdf.org/en/doc/cell.htm

[Matis]

http://www.nu.nl/column-v.../en-sepp-maar-lachen.html

Wut

[0xDEADBEEF]

Komt hiervandaan http://api.nujij.nl/NUjij2.js

code:

if (window.nujij_apikey == null)
    alert('NUjij APIkey vereist');

[BtM909]

Je eindgebruikers zijn de beste testers toch

[OkkE]

Vandaag door één van de programmeurs hier....

PHP:

function getText($slug) {
    $sql = "SELECT t_name, t_function, t_text";
    $sql .= " FROM " .getTableName('testimonial');
    $sql .= " WHERE t_slug = '" .$slug."'";
    if($results = $GLOBALS['db']->execute($sql)) {
        return $results->fetchrow();
    }
}
$item = getText($_GET['testimonial']);

[BM]

sql injection, gebruik van globals, en direct gebruik van get variabelen. Nog dingen gemist?
(note: ik ken geen php )

[Davio]

BM schreef op vrijdag 05 november 2010 @ 16:48:
sql injection, gebruik van globals, en direct gebruik van get variabelen. Nog dingen gemist?
(note: ik ken geen php )

Nah, dat was het wel ongeveer, zoiets toont toch altijd mooi aan dat iemand zijn vakgebied niet kent.

[bobo1on1]

0xDEADBEEF schreef op vrijdag 05 november 2010 @ 13:14:
Komt hiervandaan http://api.nujij.nl/NUjij2.js

code:

if (window.nujij_apikey == null)
    alert('NUjij APIkey vereist');

Bah, variabelen met Nederlandse namen.

[pieturp]

bobo1on1 schreef op vrijdag 05 november 2010 @ 21:28:
[...]

Bah, variabelen met Nederlandse namen.

Je bedoelt: "Bah variabelen in JS met underscores i.p.v. camelCase" ? Ik zie er behalve de productnaam geen Nederlands in hoor

[XWB]

Davio schreef op vrijdag 05 november 2010 @ 17:06:
[...]

Nah, dat was het wel ongeveer, zoiets toont toch altijd mooi aan dat iemand zijn vakgebied niet kent.

En de functie geeft niks terug indien geen resultaten, een return false oid kan wel handig zijn.

[Verwijderd]

En gebruik van ".="

[Jrz]

gebruik van php?

/flamebait

[bobo1on1]

pieturp schreef op vrijdag 05 november 2010 @ 21:47:
[...]


Je bedoelt: "Bah variabelen in JS met underscores i.p.v. camelCase" ? Ik zie er behalve de productnaam geen Nederlands in hoor

JavaScript:

if (window.bericht_url == null)
    var bericht_url = window.location.href;

if (window.bericht_titel == null)
    var bericht_titel = document.title;

if (window.bericht_omschrijving == null)
    var bericht_omschrijving = '';

Even op de link klikken

[Janoz]

Kom kom, we gaan toch niet weer beginnen met een discussie over de fetish van veel ontwikkelaars om zo ongeveer alles om te zetten naar (steenkolen) engels?

Bericht, titel en omschrijving zijn typische domein termen.

[pieturp]

bobo1on1 schreef op vrijdag 05 november 2010 @ 22:12:
Even op de link klikken

My bad

Maar goed, dan nog stoort 't me meer dat er underscores in variabelenamen zitten. (Maar om dat dan weer 'n WTF te noemen...)

[ Voor 5% gewijzigd door pieturp op 06-11-2010 00:02 ]

[Hillie]

Patriot schreef op woensdag 03 november 2010 @ 21:59:
maar... hoe roep je dan aan wat er in die list zit?

Je denkt dat ontwerpers van een taal en de bijbehorende compilers op een gegeven moment dachten van "Gut, nu hebben we zo'n mooie lijstiteratie, maar je kunt er eigenlijk geen fluit mee! Oh jee, nou, toch maar implementeren dan"?

Gelukkig zijn de lijstelementen toegankelijk:

code:

my_method(my_list: list of uint) is {
   for each in my_list {
      it += 1;
   };
};

Er is een keyword "it" wat je kunt gebruiken, of als je wat duidelijker wilt werken:

code:

my_method(my_list: list of uint) is {
   for each (flupke) in my_list {
      flupke += 1;
   };
};

[kenneth]

Janoz schreef op vrijdag 05 november 2010 @ 22:48:
Kom kom, we gaan toch niet weer beginnen met een discussie over de fetish van veel ontwikkelaars om zo ongeveer alles om te zetten naar (steenkolen) engels?

Bericht, titel en omschrijving zijn typische domein termen.

NowYouApiKey

[Caelorum]

kenneth schreef op zaterdag 06 november 2010 @ 10:20:
[...]
NowYouApiKey

YouAreNextApiKey? YourTurnApiKey? Bljft allemaal bagger natuurlijk.
Zo'n productnaam mag je natuurlijk wel gebruiken he! Zou raar zijn als iemand die het product ontwikkelt niet weet wat de productnaam betekent ^^

[BeerenburgCola]

PiepPiep schreef op dinsdag 02 november 2010 @ 11:48:

C:

#define     CASE_LOWER_CASE  case  'a': case  'b': case  'c': case  'd': case  'e': case  'f': case  'g': case  'h': case  'i': case  'j': case  'k': case  'l': case  'm': case  'n': case  'o': case  'p': case  'q': case  'r': case  's': case  't': case  'u': case  'v': case  'w': case  'x': case  'y': case  'z':
#define     CASE_UPPER_CASE  case  'A': case  'B': case  'C': case  'D': case  'E': case  'F': case  'G': 
...

Bron, software geschreven door een instituut dat nogal technisch hoog aangeschreven staat.

De code ziet er misschien raar uit, maar het gebruik van CASE statements kan zeer efficiënt zijn bij syntax (text) scanners. De truuk met CASE statements is namelijk dat er een jump tabel gemaakt word van de numerieke
waarden opgegeven als argument van de CASE. Dit kan zeer snelle code opleveren.

Bij het schrijven van een syntax scanner wil je zo weinig mogelijk overhead.
De code

if  c>='A'  && c<='Z' then <UPPERCASE> ...

bevat bijvoorbeeld 3 operatoren.

Als je code schrijft:

switch(c)
{
   CASE 'A':
       ...
   CASE 'B': 
      ...
}

Word de numeriek waarde van 'c' gebruik als index in een jump tabel die direct naar juist plek in de code springt. In machine taal wordt dit een soort van JMP ${<OFFSET>+c}
Er worden dan geen operatoren gebruikt om de waarde van 'c' te evalueren.

[yade]

Maar alleen bij een opeenvolgende reeks dus. Anders niet.

Maar goed, een optimizer zou ook zo geschreven kunnen zijn dat hij die if statement op dezelfde manier optimaliseert.

Hoe dan ook, welke methode is fout gevoeliger en lastiger te begrijpen?

Het moet voorop staan dat de code leesbaar en zo fout ongevoelig mogelijk is. De rest mag de compiler doen.

Maar moet iedere case niet ook iets doen? Of wordt de uitvoerbare code 26 keer gekopieerd?

Anywho, hier wil je je niet druk om maken. Ik niet in ieder geval.

[ Voor 181% gewijzigd door yade op 06-11-2010 11:57 ]

[Spinal]

Verwijderd schreef op vrijdag 05 november 2010 @ 21:56:
En gebruik van ".="

Wat is daar mis mee volgens jou?

[Gamebuster]

ZanderZ schreef op zaterdag 06 november 2010 @ 15:20:
[...]

Wat is daar mis mee volgens jou?

Ik denk dat hij bedoeld dat het zoiets had moeten zijn:

PHP:

<?php 
function getText($slug) { 
    $sql = "SELECT t_name, t_function, t_text"
        ." FROM " .getTableName('testimonial')
        ." WHERE t_slug = '" .$slug."'";
    if($results = $GLOBALS['db']->execute($sql)) { 
        return $results->fetchrow(); 
    } 
} 
$item = getText($_GET['testimonial']); 
?>

of:

PHP:

<?php 
function getText($slug) { 
    $sql = "SELECT t_name, t_function, t_text
        FROM ".getTableName('testimonial')."
        WHERE t_slug = '" .$slug."'";
    if($results = $GLOBALS['db']->execute($sql)) { 
        return $results->fetchrow(); 
    } 
} 
$item = getText($_GET['testimonial']); 
?>

[ Voor 30% gewijzigd door Gamebuster op 06-11-2010 15:35 ]

[Verwijderd]

Zou het gebruik van die operator langzamer zijn dan concatenation? En je kunt niet altijd zoveel whitespace in een string gooien zoals in het tweede voorbeeld. Ik vind dat .= nog wel het minste probleem is in die code.

[Verwijderd]

Het gebruik van ".=" is geen slecht programmeervoorbeeld, is in principe niks mis mee. Al helemaal niet als je de rest van die code ziet, dan is dat toch echt het laatste waar ik wat van zou zeggen (als ik dat al zou doen)...

[FragFrog]

Ik weet nog steeds niet of het nu geniaal is, of te ranzig voor woorden:

PHP:

    /* IF WE USE GET, PLACE THOSE VALUES IN PARAMS INSTEAD */
if($_GET) {
    $i = 0;
    foreach($_GET as $params[$i++] => $value);
}

Heel erg oude code van mezelf die ik net tegenkwam toen ik m'n blog aan het herschrijven was - een van de eerste dingen die ik ooit gedaan heb in PHP. Had serieus geen idee dat dat nog werkt ook

_{Let ook op de mooite volgorde-afhankelijkheid van de GET parameters, echt een pareltje}

[ Voor 10% gewijzigd door FragFrog op 06-11-2010 19:59 ]

[Gamebuster]

Ik moest eerst even een minuut kijken om te bepalen wat het nou eigenlijk doet, maar ben er nu uit.

Feitelijk is dat hetzelfde als:

PHP:

<?php
if($_GET)
{
  $params = array_keys($_GET);
  $value = end($_GET);
  $i = count($_GET);
}
?>

Of begrijp ik de code nu verkeerd?

Wel apart gebruik van PHP. Ik weet dat het oude code is, waarom had je de keys van _GET nodig?

Verwijderd schreef op zaterdag 06 november 2010 @ 17:21:
Zou het gebruik van die operator langzamer zijn dan concatenation? En je kunt niet altijd zoveel whitespace in een string gooien zoals in het tweede voorbeeld. Ik vind dat .= nog wel het minste probleem is in die code.

_vermoedelijk_ is het gebruik van .= trager dan de concat, omdat er dan een variable-lookup is, al zal het in praktijk denk erg weinig uitmaken. Ik ga eventjes testen

[ Voor 74% gewijzigd door Gamebuster op 06-11-2010 20:16 ]

[FragFrog]

Je interpretatie klopt volgens mij bijna: als het goed is (en ik heb het niet getest) wordt params niet de array_keys maar de array_values van GET. Feitelijk vraagt het dus op wat de waardes zijn in je GET array.

Reden waarom dit erin zit is dat het blog search-engine friendly URL's bakt, maar daarvoor zijn htaccess rules nodig. Als htaccess rewrite rules niet toegestaan zijn op een server wordt er teruggevallen op GET parameters. $params is uiteraard een global

[Gamebuster]

FragFrog schreef op zaterdag 06 november 2010 @ 20:18:
Je interpretatie klopt volgens mij bijna: als het goed is (en ik heb het niet getest) wordt params niet de array_keys maar de array_values van GET. Feitelijk vraagt het dus op wat de waardes zijn in je GET array.

Reden waarom dit erin zit is dat het blog search-engine friendly URL's bakt, maar daarvoor zijn htaccess rules nodig. Als htaccess rewrite rules niet toegestaan zijn op een server wordt er teruggevallen op GET parameters. $params is uiteraard een global

code:

foreach($_GET as $params[$i++] => $value);

$params[$i++] is de variable waaraan de key van $_GET wordt toegewezen. Aan $value wordt de waarde toegewezen.

in $params komen dus de keys te staan.

@performance testje concat vs append:
concat:
19.56 ms
19.48 ms
19.56 ms
19.48 ms
19.54 ms

append:
18.14 ms
18.12 ms
18.08 ms
18.12 ms
18.11 ms

Vreemd genoeg is append met de .= operator zelfs sneller dan de concat met de . operator in mijn testje. Had ik niet verwacht. Toch blijf ik concat gebruiken, want ik vind die netter.

Klik linkjes boven resultaten voor broncode.

[TweakPino]

yade schreef op zaterdag 06 november 2010 @ 11:40:
Maar alleen bij een opeenvolgende reeks dus. Anders niet.

Maar goed, een optimizer zou ook zo geschreven kunnen zijn dat hij die if statement op dezelfde manier optimaliseert.

Hoe dan ook, welke methode is fout gevoeliger en lastiger te begrijpen?

Het moet voorop staan dat de code leesbaar en zo fout ongevoelig mogelijk is. De rest mag de compiler doen.

Maar moet iedere case niet ook iets doen? Of wordt de uitvoerbare code 26 keer gekopieerd?

Anywho, hier wil je je niet druk om maken. Ik niet in ieder geval.

Tegenwoordig zijn compilers best slim. In dit artikel op codeproject.com wordt het switch-statement en wat de compiler ermee doet uitgebreid besproken.

[FragFrog]

Gamebuster schreef op zaterdag 06 november 2010 @ 20:27:
$params[$i++] is de variable waaraan de key van $_GET wordt toegewezen. Aan $value wordt de waarde toegewezen.

even lopen testen en inderdaad. Weer een 7 jaar oude bug opgelost

[Gamebuster]

FragFrog schreef op zaterdag 06 november 2010 @ 20:35:
[...]

even lopen testen en inderdaad. Weer een 7 jaar oude bug opgelost

Ik gebruik overigens:

code:

http://website.com/seo/vriendelijke/url.html

Waarbij .htaccess de ? ertussen plakt en .html eraf snijdt, indien die erachter staat. Ik krijg dan de volgende request:

code:

http://website.com/?seo/vriendelijke/url

Vervolgens lees ik 'm in met:

PHP:

<?$params = explode('/', $_SERVER["QUERY_STRING"])?>

Maarja, je code is 7 jaar oud
Jij hebt vast nu al genoeg betere alternatieven.

[ Voor 7% gewijzigd door Gamebuster op 06-11-2010 20:43 ]

[RomeoJ]

ZanderZ schreef op zaterdag 06 november 2010 @ 15:20:
[...]

Wat is daar mis mee volgens jou?

Als je bijvoorbeeld met Java bezig bent, dan kan je voor zulke zaken beter StringBuffer of StringBuilder gebruiken, omdat Strings 'immutable' zijn, en je op deze manier elke keer een nieuw Object aan het maken bent.

De code is echter geschreven in PHP, en daar is dit in mindere mate aan de orde, maar wil ik toch wel even aanhalen als aandachtspuntje voor overige programmeertalen. Het voorbeeld heeft tevens maar 2 concats, en zou wellicht ook overkill zijn om bovenstaande regel toe te passen.

[Verwijderd]

Wat jij zegt geldt allemaal voor Java. In andere talen werken strings anders In .NET is het bv een wrapper om een char-array

[Alex)]

Ook in .NET is een string immutable. Daarom is er ook in .NET een StringBuilder, en is String.Format() beter dan stringetjes concatenaten.

[user109731]

yade schreef op zaterdag 06 november 2010 @ 11:40:
Maar alleen bij een opeenvolgende reeks dus. Anders niet.

Hoeft niet opeenvolgend te zijn. Stel je hebt cases [1,3,5,6] dan kan de compiler een jump table maken met voor waarde 2 en 4 een jump naar de default case (of naar het volgende statement). Het enige wat van belang is is dat het verschil tussen de hoogste waarde en de laagste waarde niet te groot is. Ook een switch met cases [900, 901, 902, 903] kan efficient door overal (ook van de input) 900 af te trekken

[.oisyn]

BeerenburgCola schreef op zaterdag 06 november 2010 @ 10:55:
In machine taal wordt dit een soort van JMP ${<OFFSET>+c}
Er worden dan geen operatoren gebruikt om de waarde van 'c' te evalueren.

Hallo, meneer de 386 programmeur waar dit nog een issue was. Die vergelijking wordt wel gepipelined met andere instructies, daar hoef je je geen zorgen te maken. Belangrijker is dat de branch predictor geen brach mispredict, want dat is duur (pipeline flush). En een jump table laat zich amper goed predicten.

En idd, zoals eerder opgemerkt, een compiler ziet na het parsen echt geen verschil meer tussen een serie ifs en een switch. Die gaan uiteindelijk door hetzelfde optimizing codepath heen.

Verwijderd schreef op zaterdag 06 november 2010 @ 20:56:
Wat jij zegt geldt allemaal voor Java. In andere talen werken strings anders In .NET is het bv een wrapper om een char-array

In Java ook.

[ Voor 57% gewijzigd door .oisyn op 07-11-2010 02:00 ]

[PiepPiep]

BeerenburgCola schreef op zaterdag 06 november 2010 @ 10:55:
[...]


De code ziet er misschien raar uit, maar het gebruik van CASE statements kan zeer efficiënt zijn bij syntax (text) scanners. De truuk met CASE statements is namelijk dat er een jump tabel gemaakt word van de numerieke
waarden opgegeven als argument van de CASE. Dit kan zeer snelle code opleveren.

Bij het schrijven van een syntax scanner wil je zo weinig mogelijk overhead.
De code

if  c>='A'  && c<='Z' then <UPPERCASE> ...

bevat bijvoorbeeld 3 operatoren.

Als je code schrijft:

switch(c)
{
   CASE 'A':
       ...
   CASE 'B': 
      ...
}

Word de numeriek waarde van 'c' gebruik als index in een jump tabel die direct naar juist plek in de code springt. In machine taal wordt dit een soort van JMP ${<OFFSET>+c}
Er worden dan geen operatoren gebruikt om de waarde van 'c' te evalueren.

De define maakte in dit geval de code erg onduidelijk, de precies code heb ik op het moment even niet hier maar er stond iets als

switch(c)
{
   case '<':
       ...
   case '>':
       ...
   CASE_LOWER_CASE
       ...
   S
      ...
}

Achter de eerste 2 cases staat een dubbele punt maar achter de volgende 2 cases niet.
Die S is ook ergens met een #define gedefinieerd, maar ik (en een andere programmeur ook begreep ik later) vroeg me af of ik niet perongeluk een regel weggehaald had en op S gedrukt had.
Die CASE_LOWER_CASE zou ik ietsje minder erg vinden als ze bij de define de eerste case weg gelaten zouden hebben en CASE_ ervanaf zodat je case LOWER_CASE kan doen.
Maar goed, het geheel zit dus ook nog een vol met memory leaks en de call naar de dll geeft een block geheugen terug dat ik vanuit C# niet meer vrij kan geven.
Ook als je de functionaliteit van de dll 2 keer nodig hebt dan werkt het dus niet, alleen de 1e call gaat goed.
Dat heb ik nu opgelost door de dllimport in C# te doen in een aparte C# dll die ik via een tijdelijk appdomain aanroep en dus die appdomain kan unloaden en opnieuw loaden als ik hem nog een keer nodig heb.

[YopY]

Verwijderd schreef op zaterdag 06 november 2010 @ 20:56:
Wat jij zegt geldt allemaal voor Java. In andere talen werken strings anders In .NET is het bv een wrapper om een char-array

vzviw is er bar weinig verschil tussen de string-classes van Java en .NET - beide immutable, bij beide wordt een stringbuffer / builder verkozen boven eenvoudige concats, en beide zijn het wrappers om een char array (alhoewel je het niet als een wrapper moet zien, maar een object dat toevallig een array van chars gebruikt voor zijn interne opslag - aannames of verwachtingen over hoe een object zijn data opslaat moet je als externe gebruiker nooit gaan maken, omdat dat voor jou als gebruiker gewoon niet belangrijk is)

[Janoz]

Ach ja, veel mensen zijn in het idee blijven hangen dat Java niks meer is dan de applets die je eind jaren 90 tegen kwam. Bij die mensen kan het gewoon niet tussen de oren komen dat eigenlijk het enige echte verschil tussen Java en .NET is dat je je methodenamen met een kleine danwel hoofdletter schrijft.

Als je alleen al kijkt wat voor onzin er in nieuws: Apple stopt met ontwikkeling OS X-versie Java verkondigd werd. Ik heb al niet eens meer de moeite genomen om uberhaupt daar te proberen te reageren.

[Verwijderd]

Gamebuster schreef op zaterdag 06 november 2010 @ 20:27:
[...]

code:

foreach($_GET as $params[$i++] => $value);

$params[$i++] is de variable waaraan de key van $_GET wordt toegewezen. Aan $value wordt de waarde toegewezen.

in $params komen dus de keys te staan.

@performance testje concat vs append:
concat:
19.56 ms
19.48 ms
19.56 ms
19.48 ms
19.54 ms

append:
18.14 ms
18.12 ms
18.08 ms
18.12 ms
18.11 ms

Vreemd genoeg is append met de .= operator zelfs sneller dan de concat met de . operator in mijn testje. Had ik niet verwacht. Toch blijf ik concat gebruiken, want ik vind die netter.

Klik linkjes boven resultaten voor broncode.

Sta ik ook een beetje van te kijken. Ik ben niet zon php man, maar ik weet dat als je dit in java doet hij elke keer dat je een concat doet een nieuwe String aanmaakt. In java heb je een StringBuffer om dat op te lossen. Wellicht optimaliseert php zelf de code.

[.oisyn]

Ik vind dat resultaat eigenlijk niet meer dan logisch. Een .= past de huidige string aan, een . maakt een nieuwe string. Strings in PHP zijn value types en mutable.

[Janoz]

De beide codevoorbeeldjes verschillen alleen in vorm. Qua operaties zijn ze zo goed als hetzelfde. Het enige verschil is dat de concat telkens plakt aan de gedefinieerde string en daarvan uiteindelijk het resultaat in $str zet terwijl de append oplossing telkens het stuk tekst achter $str zet. Van optimalisatie is natuurlijk niet heel erg sprake aangezien je de sourcecode as is aan het interpreteren bent.

Echter, de reden waarom het een wat slechter programmeer voorbeeld is heeft helemaal niks te maken met efficientie. Als dergelijke efficientie blijkbaar belangrijk blijkt, dan kun je beter php overboord gooien. De reden waarom het een slecht voorbeeld is, is om dat je erg slecht het verschil ziet tussen = en .= waardoor de kans groot is dat je bugs introduceert. Bij de concat oplossing is het een stuk duidelijker wanneer je de string niet goed aan het vullen bent.


De java compiler is trouwens slim genoeg om een stukje concatenatie om te zetten naar een StringBuilder. In 99 van de 100 gevallen kun je die beter gebruiken dan de StringBuffer. StringBuffer is threadsafe, maar in de meeste gevallen heb je dat helemaal niet nodig. Omdat StringBuilder geen rekening hoeft te houden met concurrency is hij een stuk efficienter.

[RomeoJ]

Janoz schreef op maandag 08 november 2010 @ 13:47:
Bij die mensen kan het gewoon niet tussen de oren komen dat eigenlijk het enige echte verschil tussen Java en .NET is dat je je methodenamen met een kleine danwel hoofdletter schrijft.

Vraag me regelmatig af waarom die verschillen zo klein zijn, wanneer ik bijvoorbeeld aan het zoeken ben naar uitleg over methodes in Java kan ik regelmatig ook perfect uit de voeten met MSDN

Als je alleen al kijkt wat voor onzin er in nieuws: Apple stopt met ontwikkeling OS X-versie Java verkondigd werd. Ik heb al niet eens meer de moeite genomen om uberhaupt daar te proberen te reageren.

Vond ik een lange tijd ook erg vervelend als Java Software Engineer zijnde, maar kan me er nu niet meer druk om maken. Soms zijn mensen toch echt heel kortzichtig (en vooral onwetend).

[Hydra]

RomeoJ schreef op maandag 08 november 2010 @ 14:30:
Vraag me regelmatig af waarom die verschillen zo klein zijn, wanneer ik bijvoorbeeld aan het zoeken ben naar uitleg over methodes in Java kan ik regelmatig ook perfect uit de voeten met MSDN

Microsoft heeft goed naar Java gekeken, en gewoon een eigen Java versie zonder de eigenaardigheden gebouwd. Dus dit is gewoon een gevalletje beter goed gejat dan slecht zelf bedacht Bij de ontwikkeling die Java doorgemaakt heeft zijn er gewoon een aantal fouten gemaakt (vooral het AWT -> Swing -> Januwetenwehetooknietmeer gedoe) die MS heeft kunnen voorkomen.

Daarnaast maakt MS het Java devs hierdoor ook nog erg makkelijk over te stappen. Als je Java al kent is C# een eitje, en het .Net framework is ook extreem simpel opgezet, maar wel heel uitgebreid.

[Verwijderd]

heb concat, StringBuilder en StringBuffer.

StringBuilder: 573ms
StringBuilder: 199ms
StringBuilder: 411ms
StringBuilder: 221ms
StringBuilder: 162ms
StringBuffer: 310ms
StringBuffer: 291ms
StringBuffer: 320ms
StringBuffer: 310ms
StringBuffer: 318ms
Concat: 1207ms
Concat: 1008ms
Concat: 956ms
Concat: 897ms
Concat: 918ms

[ Voor 37% gewijzigd door Verwijderd op 08-11-2010 15:17 ]

[roy-t]

.NET Java noemen met Hoofdletters vind ik wel een beetje kort door de bocht.

Java staat nu al een jaar of 4 stil, is het niet? .Net 3.5 en 4.0 brachten veel vernieuwingen, maar als je ziet wat de nieuwe features in java 1.7 zijn, dan mja.. kijken jullie zelf maar .
http://inebium.com/post/java-7-new-release-performance-code

-Betere support voor collections, soort shorthand notation.

Java:

List<String> list = ["item"];
String item = list[0];

Set<String> set = {"item"};

Map<String, Integer> map = {"key" : 1};
int value = map["key"];

-Een soort van 'using' construct in dat automatisch de dispose()/close() functie wordt aangeroepen van BufferedReader e.d.

-Underscores in numeric literals? Waarom?

Java:

int billion = 1_000_000_000;

-Strings in switch (eindelijk)

-Binary literals?

Java:

int binary = 0b1001_1001;

-Betere performance (altijd goed natuurlijk, wat mini testjes geven +- 5% betere performance voor simpele taken als veel strings ergens heen gooien).


Allemaal leuke kleine dingetjes, maar als je dit vergelijkt met al die nieuwe dingen in .Net3.5 en 4.0 (waar bijvoorbeeld PXF wel een hele goede is, de rest gebruik ik nog weinig) dan is het toch een beetje zuur dat het nu al 4 jaar duurt.

Nog een stukje waarom er nog geen nieuwe java is

quote: http://stackoverflow.com/...g-the-release-of-java-1-7

Although Sun open-sourced Java SE, they did not open-source the test suites required to claim conformance. This caused a conflict with the Apache foundation. Many members of the JCP executive committees, whose votes are required for JSRs to become final, support Apache in this conflict. Consequently, many JCP executive committees have agreed not to approve any of Sun's JSRs until the license terms are "fixed". Sun has avoided filing JSRs that they know will be shot down. Without an umbrella JSR for Java SE 7, there is no Java SE 7.

So depending on whose side you take, the answer to "Who is preventing the release of Java 1.7" is either Sun Microsystems or the Apache Foundation.

Incidentally, Oracle was a strong supporter of the Apache foundation, and Oracle has now purchased Sun Microsystems. That may provide hope for breaking the logjam.

Stephen Colebourne has written about these issues: http://www.jroller.com/scolebourne/date/20090328 http://www.jroller.com/scolebourne/date/20090416 http://www.jroller.com/scolebourne/date/20090421.

[Gamebuster]

Verwijderd schreef op maandag 08 november 2010 @ 15:15:
heb concat, StringBuilder en StringBuffer.

StringBuilder: 573ms
StringBuilder: 199ms
StringBuilder: 411ms
StringBuilder: 221ms
StringBuilder: 162ms
StringBuffer: 310ms
StringBuffer: 291ms
StringBuffer: 320ms
StringBuffer: 310ms
StringBuffer: 318ms
Concat: 1207ms
Concat: 1008ms
Concat: 956ms
Concat: 897ms
Concat: 918ms

Lekker consequent. Broncode? Taal?

roy-t schreef op maandag 08 november 2010 @ 15:28:
.NET Java noemen met Hoofdletters vind ik wel een beetje kort door de bocht.

Java staat nu al een jaar of 4 stil, is het niet? .Net 3.5 en 4.0 brachten veel vernieuwingen, maar als je ziet wat de nieuwe features in java 1.7 zijn, dan mja.. kijken jullie zelf maar .
http://inebium.com/post/java-7-new-release-performance-code

*lijstje*

Die nieuwe Java features zijn nou niet echt dingen waar ik voor sta te springen. Die shorthand notation collections zijn leuk, maar daar houd het ook bij op.

[ Voor 93% gewijzigd door Gamebuster op 08-11-2010 15:38 ]

[CodeCaster]

Hydra schreef op maandag 08 november 2010 @ 15:08:
[...]
Daarnaast maakt MS het Java devs hierdoor ook nog erg makkelijk over te stappen. Als je Java al kent is C# een eitje, en het .Net framework is ook extreem simpel opgezet, maar wel heel uitgebreid.

Vergeet vooral de goddelijke MSDN niet. Ik heb zelden een zo duidelijke handleiding van een programmeertaal of een framework gezien.

[Janoz]

Zoals Hydra al aangaf, ze hebben goed naar java gekeken. Javadoc is zo ongeveer onderdeel van de taal en platform specificatie .

[.oisyn]

Behalve dan dat de MSDN docs al bestonden voordat Java bestond

[Janoz]

Maar werd/wordt dat ook vanuit de sourcecode gegenereerd? (Daar doelde ik eigenlijk meer op)

[Davio]

CodeCaster schreef op maandag 08 november 2010 @ 15:37:
[...]

Vergeet vooral de goddelijke MSDN niet. Ik heb zelden een zo duidelijke handleiding van een programmeertaal of een framework gezien.

Second that. Ik kom vaak als ik google op een bepaald probleem gewoon op de MSDN uit waar een duidelijk voorbeeld staat. Vandaag nog omdat ik handmatig een connection string moest bouwen en het niet voldoende was de string uit de appSettings xml-file te copy-pasten en wat dingen daarin aan te passen.

[.oisyn]

Janoz schreef op maandag 08 november 2010 @ 15:55:
Maar werd/wordt dat ook vanuit de sourcecode gegenereerd? (Daar doelde ik eigenlijk meer op)

Geen idee maar de MSDN documentatie bestaat uit een stuk meer dan louter de API reference - zoals examples, how to's, whitepapers, etc. En dat zijn juist de dingen die het imho zo duidelijk maken. Als ik iets wil ben ik in eerste instantie niet geïnteresseerd in klasse-documentatie. Hell, ik weet nog niet eens welke klasse ik moet gebruiken. Ik wil liever eerst een stukje background over het onderwerp en relevante terminologie.

Het grote probleem van de java docs was ten eerste dat de API reference compleet los stond van de rest, en dat er maar weinig in-depth artikelen over verschillende dingen waren. Dan ga je op zoek naar classes in packages die waarschijnlijk wel doen wat je wil, en moet je een beetje gaan puzzelen om erachter te komen hoe je de juiste componenten aan elkaar knoopt (hmm de ctor van klasse X wil interface Y waar geen concrete implementatie van bestaat, nu moet ik dus op zoek naar klasse Z die een instance naar Y returnt... of moet ik 'm soms zelf implementeren ). Maar dat was 10 jaar geleden, geen idee hoe het nu is

[ Voor 32% gewijzigd door .oisyn op 08-11-2010 16:31 ]