De Devschuur Coffee Corner

[mux]

Exirion schreef op zaterdag 03 juli 2010 @ 00:07:
[...]

Onzinnig statement. In de jaren 90 was OOP het sleutelwoord en moest alles OOP zijn om als fatsoenlijk gemodelleerd beschouwd te worden. Dat veel mensen leren programmeren in object-georienteerde talen wil niet zeggen dat niet-OO talen daarom geen goeie software kunnen opleveren. Veel mensen zijn bang voor C of weten er niet mee om te gaan. OO is niet heilig en in C kun je net als in C++ prima software schrijven. Sterker nog, overgestructureerde C++ code kan soms zo omslachtig/krampachtig opgezet zijn dat je hetzelfde in veel minder code met C kunt doen, en zodanig dat het overzicht over het geheel beter is.

Hm, totaal niet wat ik bedoel eigenlijk. In C++ wordt het als evil gezien om met pointers en dat soort meuk te spelen, terwijl dat in embedded hardware bittere noodzaak is. In C++ heb je een miljard mogelijkheden tot verregaande abstractie, terwijl je in embedded hardware (ok, ik praat nu echt over ARM7 en simpeler) simpelweg het geheugen niet hebt om te generaliseren of abstraheren. C is daarentegen weer veel fijner dan de meeste andere talen in dat je pointers en structs kúnt gebruiken. Dat maakt C dus een meer-dan-voldoende taal voor embedded, en een mooi compromis tussen asm en abstractere (bijv. OO) talen. Of, anders gezegd, C++ voegt eigenlijk niks toe voor echt low-level embedded spul. Je gebruikt C stiekum gewoon als 'makkelijke' assembler.

Aan de andere kant van het verhaal heb je high-level OS-meuk waar je écht geen tijd en zin hebt om de honderd miljard interfaces te gaan bestuderen. Je wilt abstractie, je wilt alle complexiteit wegijken, je wilt prototypes en je wilt dynamic binding zodat maintainability nog enigszins makkelijk blijft voor je ooit-glorieus-geprogrammeerde projecten. Je hebt de luxe dat een x86-monster tientallen miljoenen interrupts per seconde en giga-instructies per seconde kan verwerken, en bovendien terabytes opslag heeft, dus mag je wel ietsjes meer overhead genereren om het jezelf makkelijk te maken. Ik zeg niet dat dit met C niet kan, ik zeg alleen dat C++ het IMO makkelijker maakt, net als bijvoorbeeld Java (wat wmb ook een prima platform is voor high-level zut).

Nou programmeer ik zelf bijna exclusief voor AVRs, ARM7, TMS320 en andere simpele microcontrollers, dus ik kom ook niet bepaald intensief in contact met C++, dus een .oisyn kan hier intelligentere opmerkingen over maken, maar dit is wat ik erover denk.

Ligt het trouwens aan de hitte of zijn jullie altijd zulke vechtersbaasjes?

[Woy]

Ik heb even wat berichten verwijderd, laten we het hier gewoon gezellig houden.

[Exirion]

ssj3gohan schreef op zaterdag 03 juli 2010 @ 09:00:
Hm, totaal niet wat ik bedoel eigenlijk.

Ik begrijp nu beter wat je bedoelde. Neemt niet weg dat ik nogsteeds vind dat ook grote complexe software op x86 systemen net zo goed en gestructureerd in C als in C++ kan zijn. Het is gewoon in een andere mindset werken, en het is voor een groot deel van je achtergrond en werkdomein afhankelijk waarin je het fijnste/beste werkt.

Nou programmeer ik zelf bijna exclusief voor AVRs, ARM7, TMS320 en andere simpele microcontrollers, dus ik kom ook niet bepaald intensief in contact met C++, dus een .oisyn kan hier intelligentere opmerkingen over maken, maar dit is wat ik erover denk.

In mijn werk draait het ook voornamelijk om embedded systemen, dus ik werk net als jij vaker met C en MIPS/ARM assembly dan met C++. Ik twijfel er dan ook niet aan dat .oisyn de ins en outs van C++ veel beter kent dan ik. Maar het is ook weer niet zo dat een afkeer tegen C++ of OO heb. Sterker nog, ik heb Delphi en C++ builder een tijd intensief gebruikt. De laatste jaren werk ik regelmatig aan cross-platform software met C++ frameworks, maar ook OSX en iPhone software in Objective C. Deze week toevallig ben ik me hobbymatig bezig met het porten van een eigen Cocoa app naar Windows met Cocotron (Windows port van Cocoa). Het is echt niet dat ik alleen C goed vind ofzo.

Ligt het trouwens aan de hitte of zijn jullie altijd zulke vechtersbaasjes?

Zal vast aan de hitte liggen. Doen we anders nooit

[Refro]

ssj3gohan schreef op zaterdag 03 juli 2010 @ 09:00:
[...]


Hm, totaal niet wat ik bedoel eigenlijk. In C++ wordt het als evil gezien om met pointers en dat soort meuk te spelen, terwijl dat in embedded hardware bittere noodzaak is. In C++ heb je een miljard mogelijkheden tot verregaande abstractie, terwijl je in embedded hardware (ok, ik praat nu echt over ARM7 en simpeler) simpelweg het geheugen niet hebt om te generaliseren of abstraheren.

Daar heb je tot op een zekere hoogte zeker gelijk in maar met de hardware prijzen die hard gezakt zijn kan het nuttig zijn een andere processor uit te zoeken. Wij verkopen ongeveer 1000 controls met voorheen een x270 maar deze trok het maar net we zijn dus overgestapt naar een omap die het met gemak trekt de aanpassingen in software waren gewoon duurder als de aanpassingen van de hardware (das inclusief bsp opnieuw customizen en redesign van het carrier board.) Met hogere oplages worden hardware kosten wel weer belangrijker. Voor ons IOBoard dat appletalk en een eigen industriele bus moet kennen hebben we dezelfde stap gemaakt in de ARM7 familie.

C is daarentegen weer veel fijner dan de meeste andere talen in dat je pointers en structs kúnt gebruiken. Dat maakt C dus een meer-dan-voldoende taal voor embedded, en een mooi compromis tussen asm en abstractere (bijv. OO) talen. Of, anders gezegd, C++ voegt eigenlijk niks toe voor echt low-level embedded spul. Je gebruikt C stiekum gewoon als 'makkelijke' assembler.

C is inderdaad prachtig maar nodigt in mijn ervaring minder uit om netjes te werken als is het zeker heel goed mogelijk. Ook om zaken af te schermen en netjes in uitwisselbare blokjes op te zetten moet je moeilijker doen. En heb je al heel snel functie pointers met hun vage syntax nodig (die de helft van de mensen op de afdeling niets eens beheerst terwijl ze alleen in C programmeren, maar dat zegt meer over de afdeling).

Nou programmeer ik zelf bijna exclusief voor AVRs, ARM7, TMS320 en andere simpele microcontrollers, dus ik kom ook niet bepaald intensief in contact met C++, dus een .oisyn kan hier intelligentere opmerkingen over maken, maar dit is wat ik erover denk.

Ik heb in het verleden tot 2 jaar terug ook voornamelijk voor 8051, avr en 80166 geprogrammeerd. Maar met een nieuw project zijn we naar C++ op die x270 gegaan en hier heb ik erg veel van geleerd ook zaken die in weer kan toepassen als ik later weer terug naar de lagere platforms ga.

[Exirion]

Refro schreef op zaterdag 03 juli 2010 @ 09:57:
Daar heb je tot op een zekere hoogte zeker gelijk in maar met de hardware prijzen die hard gezakt zijn kan het nuttig zijn een andere processor uit te zoeken.

Je hebt gelijk dat je voor dezelfde prijs steeds zwaardere platformen kunt krijgen, maar het is niet zo dat alles alleen maar omhoog geschaald wordt. Het is eerder zo dat de diversiteit aan platformen is gegroeid, en als je naar Cortex M0/M3 systemen kijkt dan zie je dat goedkope/lichte/zuinige platformen helemaal actueel zijn. Daar is de software ook naar: op een OMAP draai je simpelweg Linux met glibc of uclibc. Op zo'n Cortex M met een paar KB aan RAM draai je een RTOS met een minimale footprint. Het is maar net in wat voor business je zit. Als het om grote volumes gaat dan is de bare minimum goed genoeg, als het maar goedkoop is.

[mux]

@Refro: ik ben het niet meteen eens (niet dat jij stelt dat dit onvoorwaardelijk zo is) dat iedereen opschaalt in computationele kracht om te compenseren voor oneindig optimaliseren van code. Dit is tweeledig:

- Je kunt je meestal hoe dan ook geen grotere computationele complexiteit veroorloven in bijvoorbeeld intensief gebruikte interrupts. Een O(nlogn) versus O(n^2) is gewoon niet mogelijk, hoever je je microcontroller ook overklokt of een betere architectuur gebruikt. Het verschil tussen 'de snelste' en 'de langzaamste' is afgezien van CE-SoCs maar een factor 10 ofzo. Daar los je een echt inefficient algoritme gewoon niet mee op
- Zoals Exirion zegt: low-cost en vooral low-power programmeerbare chips zijn zwaar in opkomst. Waar eerst nog analoge oplossingen nodig waren kan dit nu allemaal in space-saving, goedkope microcontrollers (denk eens aan SOT-23 AVRs en MSP430s). Plekken waar echt high-performance spul nodig is... dat wordt meestal door DSPs, FPGAs, CPLDs afgevangen.

Dus, hoe dan ook blijft het relatief kritiek om op je resources te zitten bij embedded toepassingen (in de zin waar ik het nu dus over heb). Ik heb het dan niet over Atom, high-end consumer electronics en dat soort zut, dat zijn gewoon kleine computers met high-level OS en al dat soort spul.

Voordat mensen hier weer over beginnen: ik wil natuurlijk niet impliceren dat C++ per definitie slomer, netter, OO of wat dan ook is. Noch dat je niet netjes kunt structureren en met een beetje moeite zelfs dingen forward compatible kunt maken met andere libs.

[Jan_V]

Met al dat praat over C en C++ stijgt er bij mij ineens de noob vraag in welke environment jullie werken? Is dat tegenwoordig nog steeds C++ Builder (Borland), of is daar tegenwoordig ook iets beters/moderners voor te verkrijgen? Gaat volgens mij niet met een moderne VS werken dacht ik.

[Comp_Lex]

Ik werk zelf momenteel met Code::Blocks.

[whoami]

[b][message=34284843,noline]Gaat volgens mij niet met een moderne VS werken dacht ik.

Waarom denk je dat ?

[dtech]

Jan_V schreef op zaterdag 03 juli 2010 @ 18:45:
Met al dat praat over C en C++ stijgt er bij mij ineens de noob vraag in welke environment jullie werken? Is dat tegenwoordig nog steeds C++ Builder (Borland), of is daar tegenwoordig ook iets beters/moderners voor te verkrijgen? Gaat volgens mij niet met een moderne VS werken dacht ik.

Visual studio werkt enkel met managed C++. En als je toch .NET gebruik kun je imho beter C# gebruiken (daar kun je ook met pointers e.d. werken in unmanaged code)

C werk wordt meestal gewoon in een "simpele" editor of vi ofzo gedaan. Het is toch een taal die zich beter leent voor toepassingen en grote van projecten die je ook met een editor nog goed kunt handhaven.
Voor het sirieuzere werk is Borland nog redelijk populair, Eclipse (met cdt plugin) is ook erg populair.

[Sebazzz]

dtech schreef op zondag 04 juli 2010 @ 00:27:
[...]


Visual Studio werkt enkel met managed C++. En als je toch .NET gebruik kun je imho beter C# gebruiken (daar kun je ook met pointers e.d. werken in unmanaged code)

Dat is dus heel erg onjuist. Visual Studio heeft zowel support voor unmanaged C++ als managed (CLR) C++. En je bedoeld niet in C# unmanaged code, maar unsafe code.

Nu is dit een screenshot van Visual Studio 2010 maar het was al zo vanaf de eerste Visual Studio ('97) dat je unmanaged C++ kon gebruiken en dat is nooit veranderd, en zal het ook voorlopig even niet doen.

Ik ben overigens wel geïnteresseerd waar games in gemaakt worden. Van de ID tech 4 spellen weet ik dat Visual Studio gebruikt wordt, maar hoe zit het met de rest?

[ Voor 36% gewijzigd door Sebazzz op 04-07-2010 00:40 ]

[.oisyn]

Visual Studio bestaat idd pas sinds '97, maar dat is slechts de bundel van alle losse onderdelen die al veel eerder bestonden. VS '97 bestond namelijk uit oa Visual Basic 5 en Visual C++ 5. VC++ 1.0 stamt uit '93.

Daarnaast is native C++ uiteraard nog altijd mogelijk, dat is met VC++ 2010 zo en zal met de toekomstige versies ook nog heel lang het geval blijven. Native C++ heeft nog een veel te grote marktwaarde om voor MS genegeerd te worden, en daarnaast is het overgrote deel van de Windows codebase ook nog altijd C en/of C++ (al gebruiken ze geloof ik zelf niet de VS IDE daarvoor).

Overigens is "Managed C++" een verouderde term die nog in VS 2002 en 2003 gebruikt werd. Met VC++ 8 (VS 2005) werd C++/CLI geïntroduceerd, een gestandaardiseerde taal waarin .Net constructies veel mooier in de taal waren opgenomen (oa door gebruik te maken van context sensitive keywords als "ref class", en nieuwe managed pointer en reference types dmv ^ en %)

Ik ben overigens wel geïnteresseerd waar games in gemaakt worden. Van de ID tech 4 spellen weet ik dat Visual Studio gebruikt wordt, maar hoe zit het met de rest?

Wellicht gebruikt niet iedereen de IDE, maar vrijwel iedereen die voor Windows ontwikkeld gebruikt de VC++ compiler. En voor Xbox 360 development zit je sowieso vast aan de VC++ compiler, ik geloof niet dat er andere compilers voor bestaan (en de 360 PowerPC is niet binary compatible met de algemene PowerPC, al zijn de verschillen niet heel erg groot - met name 128 ipv 32 AltiVec registers en wat extra instructies zoals een single cycle dotproduct)

[ Voor 13% gewijzigd door .oisyn op 04-07-2010 01:00 ]

[Sebazzz]

Wellicht gebruikt niet iedereen de IDE, maar vrijwel iedereen die voor Windows ontwikkeld gebruikt de VC++ compiler.

Wat voor IDE moet ik dan aan denken? Borland of een bedrijfs (propietary) IDE?
En de VC++ compiler is zeker vanwege optimalisatie oid?

(al gebruiken ze geloof ik zelf niet de VS IDE daarvoor).

Van wat ik begrijp is VS 2010 in .NET zelf geschreven

[.oisyn]

Sebazzz schreef op zondag 04 juli 2010 @ 00:56:
[...]
Wat voor IDE moet ik dan aan denken? Borland of een bedrijfs (propietary) IDE?

Whatever ze maar willen gebruiken.

En de VC++ compiler is zeker vanwege optimalisatie oid?

Mwoa, Intel C++ doet dat wat beter op zich.

Van wat ik begrijp is VS 2010 in .NET zelf geschreven

Wat ik bedoel is dat ze de VC++ IDE niet gebruiken om hun C en C++ projecten te managen.

[Jan_V]

whoami schreef op zaterdag 03 juli 2010 @ 21:43:
[...]
Waarom denk je dat ?

Dacht dat ze dat er in de loop der jaren wel hadden uit gehaald om zo iedereen te pushen om C++.NET te gebruiken.
Aan de hand van de reacties en de screenshot van Sebazzz zie ik dat mijn gedachtengang niet correct was.

[Sebazzz]

Ik denk dat Microsoft liever heeft dat mensen C# dan C++/CLI gebruiken. Ze vinden pointers de root of all evil, en in sommige gevallen klopt dat ook.

[mux]

Ik doe af en toe nogal esoterische algoritme-implementaties samen met iemand anders, die persoon produceert het meest geweldige commentaar op code. Hij zou proberen met wat slim gegoochel de performance van mijn laatste aes-implementatie in javascript omhoog te krikken (nu doet hij ~1MB/s). Nog voordat hij iets van de code gelezen heeft:

code:

Hij: ik zal eens naar je aes-programma kijken, daar kan vast nog wel een factor 10 van af :P
Ik: goedhoor
voorlopig gebruik ik hem alvast
Hij: is prima; ik zal de interface handhaven
Ik: huidige performance staat in de comments
Hij: mijn god
je hebt de verkeerde tabs gebruikt
Ik: :P
ik houd me er tegenwoordig netjes aan hoor
Hij: 4 spaties
Ik: oh, ik gebruik elke keer een andere notepad++ dus die instellingen vergeet ik
Hij: find-replace met 4 spaties werkt bijna perfect

Hetzelfde met braces, whitespace, etc. Hij staat erop dat in js:

code:

function([arguments]){
    (... statements ...);
}

gebruikt, en niet die eerste brace op een newline!

[Sebazzz]

Dat laatste is gewoon voorkeur. Ik vind code sneller te lezen en minder error-prone als je de opening brace op dezelfde lijn zet als een functiedeclaratie, of if statement. Naar mijn ervaring werkt het qua formatting ook net wat lekkerder als je dit doet.

[ Voor 31% gewijzigd door Sebazzz op 04-07-2010 15:51 ]

[.oisyn]

Sebazzz schreef op zondag 04 juli 2010 @ 13:48:
Ik denk dat Microsoft liever heeft dat mensen C# dan C++/CLI gebruiken. Ze vinden pointers de root of all evil, en in sommige gevallen klopt dat ook.

Als je pure C++/CLI schrijft dan kun je ook geen pointer gebruiken. Omgekeerd kun je met unsafe C# code ook wel gewoon pointers gebruiken .

Maar idd, C# is imho de ideale .Net taal. C++/CLI is vooral handig als je veel native interop moet doen, wat een stuk beter werkt dan P/Invoke.

[ Voor 16% gewijzigd door .oisyn op 04-07-2010 21:41 ]

[Amras]

Sebazzz schreef op zondag 04 juli 2010 @ 15:27:
Dat laatste is gewoon voorkeur. Ik vind code sneller te lezen en minder error-prone als je de opening brace op dezelfde lijn zet als een functiedeclaratie, of if statement. Naar mijn ervaring werkt het qua formatting ook net wat lekkerder als je dit doet.

In Javascript is dat zeker geen voorkeur! Voorbeeld:

JavaScript:

return
{
    foo: 'bar'
}

doet iets anders dan:

JavaScript:

return {
    foo: 'bar'
}

In alle overige talen ben ik het met je eens trouwens.

[Sebazzz]

Jij had het over een functiedeclaratie, niet over een return statement

[ Voor 3% gewijzigd door Sebazzz op 04-07-2010 22:14 ]

[Amras]

Ik geef een voorbeeld waarin het haakjesgebruik geen voorkeur is, maar waar het gewoon fout kan gaan. Bij het aanmaken van een object literal zou je er voor kunnen kiezen het eerste haakje op een nieuwe regel te zetten, maar door semicolon insertion in Javascript levert dit iets anders op dan je zou verwachten.

[.oisyn]

Ik vind Javascript op zich een mooie taal, maar die hele semicolon insertion gaat nergens over. Maar goed, het ligt natuurlijk wel geheel in de lijn van destijds dat de browser maar zoveel mogelijk user-errors op moest kunnen lossen.

[Soultaker]

Waarom "gaat dat nergens over"? Go en Python en doen soortgelijke dingen en dat zijn geen talen die automatisch user-errors willen opvangen.

Het achterliggende idee is dat programmeurs er toch al code standards op nahouden, waarbij de correcte formattering van bepaalde syntactische constructies vastgelegd wordt. In juist geformatteerde code is er dus een wederzijdse redundantie tussen syntax en formattering. Waarom zou je die redundantie dan niet elimineren om de programmeertaal simpeler en consistenter te maken, door de syntax af te leiden uit de formattering?

[.oisyn]

Soultaker schreef op zondag 04 juli 2010 @ 23:02:
Waarom "gaat dat nergens over"? Go en Python en doen soortgelijke dingen en dat zijn geen talen die automatisch user-errors willen opvangen.

Go en Python doen echt hele andere dingen dan Javascript. Javascript is een C-like taal, Go en Python niet. De formatting ligt voor Go en Python vast, voor Javascript niet, net zoals bij alle C-like talen. Echter, wat javascript toevoegt is dat een \n op een plek waar een semicolon syntactisch correct zou zijn ook als semicolon geldt, maar op andere plekken niet. Dit doet dus gewoon niet wat je van een C-like taal zou verwachten:

JavaScript:

function foo()
{
    return
        new Bar();
}

Dit dan weer wel

JavaScript:

function foo()
{
    return 3 +
        4;
}

En dit weer niet

JavaScript:

function foo()
{
    return 3
        + 4;
}

(.edit: nee dus, om maar weer aan te geven hoe complex de regels eigenlijk zijn. Beide laatste voorbeelden returnen gewoon 7. Maar het eerste voorbeeld returnt undefined.
Ook een leuke, wat doet de volgende code?

JavaScript:

a = b
(c).print()

)
Als je bij een taal-ontwerp uitgaat van syntaxregels van andere talen, dan moet je de boel niet ingewikkelder en onintuitiever maken. Als je per se een enter als end-of-statement wilt, dan moet je ook kiezen voor een geheel andere syntax.

Het achterliggende idee is dat programmeurs er toch al code standards op nahouden, waarbij de correcte formattering van bepaalde syntactische constructies vastgelegd wordt.

Het hele punt is dat javascript dat dus helemaal niet doet. Het boeit echt totaal niet welke indenting e.d. je gebruikt. Iets als

JavaScript:

if (a) b; c;

zal altijd c uitvoeren.

Die hele semicolon insertion maakt de JS grammatica ook nog eens onnodig gecompliceerd.

En elk fatsoenlijk javascript tutorial of boek raadt gewoon aan om te allen tijde gewoon semicolons te gebruiken. Dus wat is er dan nou uiteindelijk mee gewonnen? Nou, dat dingen als <body onload="foo()"> geen syntax error opleveren.

Wat leesvoer: http://inimino.org/~inimino/blog/javascript_semicolons

.edit: nog een leuke, waar zelfs de syntax highlighter op fout gaat

JavaScript:

s = "string"
a = b
/in/g.exec(s)

Ik hoop dat je het inmiddels met me eens bent dat dit daadwerkelijk nergens over gaat.

[ Voor 34% gewijzigd door .oisyn op 04-07-2010 23:43 ]

[CoolGamer]

.oisyn schreef op zondag 04 juli 2010 @ 23:15:
Echter, wat javascript toevoegt is dat een \n op een plek waar een semicolon syntactisch correct zou zijn ook als semicolon geldt, maar op andere plekken niet.

Niet helemaal waar:

quote: http://www.ecma-internati...iles/ECMA-ST/ECMA-262.pdf

There are three basic rules of semicolon insertion:
1. When, as the program is parsed from left to right, a token (called the offending token) is encountered that is not allowed by any production of the grammar, then a semicolon is automatically inserted before the offending token if one or more of the following conditions is true:
• The offending token is separated from the previous token by at least one LineTerminator.
• The offending token is }.

2. When, as the program is parsed from left to right, the end of the input stream of tokens is encountered and the parser is unable to parse the input token stream as a single complete ECMAScript Program, then a semicolon is automatically inserted at the end of the input stream.

3. When, as the program is parsed from left to right, a token is encountered that is allowed by some production of the grammar, but the production is a restricted production and the token would be the first token for a terminal or nonterminal immediately following the annotation “[no LineTerminator here]” within the restricted production (and therefore such a token is called a restricted token), and the restricted token is separated from the previous token by at least one LineTerminator, then a semicolon is automatically inserted before the restricted token.

However, there is an additional overriding condition on the preceding rules: a semicolon is never inserted automatically if the semicolon would then be parsed as an empty statement or if that semicolon would become one of the two semicolons in the header of a for statement

Dus hij plaatst een ";" zodra de token op de volgende regel niet binnen de grammatica past. Bij een aantal keywords is het niet toegestaan om een enter te laten volgen voor de rest van het statement.

EDIT: Dit verklaart ook waarom deze twee 7 als resultaat geven:

JavaScript:

function foo()
{
    return 3 +
        4;
}
function foo()
{
    return 3
        + 4;
}

Als je kijkt naar de definitie van een functie:

code:

ReturnStatement :
return [no LineTerminator here] Expressionopt ;

Terwijl het met deze definitie logisch is dat deze code de functie "b" aanroept:

JavaScript:

a = b
(c).print()

EDIT2: Misschien wel even handig om alle statements te laten zien waar geen linebreak mag volgen:

LeftHandSideExpression [no LineTerminator here] ++
LeftHandSideExpression [no LineTerminator here] --
continue [no LineTerminator here] Identifieropt
break [no LineTerminator here] Identifieropt
return [no LineTerminator here] Expressionopt
throw [no LineTerminator here] Expression

Dus

JavaScript:

function foo() {
++
a; //mag
a
++; // mag niet
}

[ Voor 17% gewijzigd door CoolGamer op 05-07-2010 00:16 ]

[.oisyn]

TheCoolGamer schreef op zondag 04 juli 2010 @ 23:57:
[...]


Niet helemaal waar:

Zoals ik al zei in mijn edit

Als je kijkt naar de definitie van een functie:

Die productieregel heeft niets met die code te maken. Je moet kijken naar de productieregel van een expressie.

[ Voor 33% gewijzigd door .oisyn op 05-07-2010 02:10 ]

[Soultaker]

.oisyn schreef op zondag 04 juli 2010 @ 23:15:
Go en Python doen echt hele andere dingen dan Javascript. Javascript is een C-like taal, Go en Python niet.

Mwoah, ik vind in ieder geval Go behoorlijk C-like. En in Python kan ik precies dezelfde misleidende code schrijven:

Python:

def func():
  return 123
  + 456

De formatting ligt voor Go en Python vast, voor Javascript niet, net zoals bij alle C-like talen. Echter, wat javascript toevoegt is dat een \n op een plek waar een semicolon syntactisch correct zou zijn ook als semicolon geldt, maar op andere plekken niet.

Dat doet Go dus ook. Voordeel van Go is wel dat het een statisch getypeerde taal is met een vrij stricte compiler, die bijvoorbeeld "+3" niet als statement toestaat (wat in de meeste talen geen enkel probleem is), maar het principe is niet anders. De formele syntax is nog steeds gedefinieerd met de puntkomma-syntax en je kunt ook nog steeds puntkomma's toevoegen, maar er worden nét als in JavaScript puntkomma's automatisch ingevoegd waar dat kan, vandaar dat je niet dit kunt schrijven:

Go:

func foo() int
{
    return 123
}

Maar wel:

Go:

func foo() int { x := 100; y := 20; z := 3; return x + y + z }

Ik zie niet in waarom JavaScript fundamenteel slechter zou zijn dan Go of Python, terwijl in alledrie de talen de formattering syntactische betekenis heeft. Ja, het klopt dat je daardoor enige vrijheid verliest in de formattering van je code. Maar daar staat tegenover dat de code zelf simpeler kan worden.

Dit doet dus gewoon niet wat je van een C-like taal zou verwachten:

JavaScript:

function foo()
{
    return
        new Bar();
}

Doe dat dan ook niet. Zowel in JavaScript als in Python kun je (en in Python móet je) haakjes toevoegen als je een expressie wil schrijven die meerdere regels beslaat. Dat is toch niet zo ingewikkeld? Overigens heb ik nog nooit de neiging gehad om code te schrijven zoals je die als voorbeeld opvoert, ook niet in C.

Elke taal heeft syntactische regels waar je je aan moet houden. Ik klaag ook niet dat ik in C mijn statements en declaraties met puntkomma's moet afsluiten. Of dat ik in C++ een spatie na de > van een geneste template parameter moet zetten. Als de regels maar logisch en enigzins praktisch zijn, vind ik het best.

En elk fatsoenlijk javascript tutorial of boek raadt gewoon aan om te allen tijde gewoon semicolons te gebruiken.

Er staat zoveel onzin in programmeerboeken. Wat mij betreft valt dit soort adviezen in dezelfde categorie als het advies om floating point berekeningen altijd met een marge te controlleren omdat ze inherent onnauwkeurig zijn. Dat is complete flauwekul want ze zijn perfect deterministisch, maar veel mensen zijn lui en in plaats van uit te zoeken hoe ze precies werken en na te denken bij de code die ze schrijven, blijven ze met onhandige workarounds werken om maar te voorkomen dat ze hun verstand hoeven te gebruiken. Waarom zou je in godsnaam "te allen tijden" semicolons invoegen? Zodat je niet hoeft te begrijpen wanneer ze wel en niet nodig zijn? Hoe ga je dan om met het debuggen van onverwachte problemen of het lezen van code van anderen, die er niet dezelfde conventie op nahouden?

De bron die je zelf aanhaalt concludeert dat bovendien ook:

http://inimino.org/~inimino/blog/javascript_semicolons
Many new JavaScript programmers are advised to just use semicolons everywhere, and expect that if they do not intentionally use the semicolon insertion rules, they can safely ignore the existence of this entire language feature. This is not the case, because of the restricted productions described above, notably the return statement. When becoming aware of the restricted production issue, programmers may then become overly wary of linebreaks, and avoid them even when they would increase clarity. It is best to be familiar with all the rules for ASI so as to be able to read any code regardless of how it is written, and to write code that is as clear as it can be.

Another misconception is that bugs in browser JavaScript engines mean that using semicolons everywhere is safer, and will protect the developer from compatibility issues between browsers. This is simply not the case. All extant browsers implement the specification correctly with regard to ASI, and any bugs that may have existed are long since lost in the mists of early Web history. There is no reason to be concerned about browser compatibility in regard to semicolon insertion: all browsers implement the same rules and they are the rules given by the spec and explained above.

Overigens vind ik (ook?) dat zowel Python als Go dit probleem stuk eenvoudiger en beter aangepakt hebben, maar het principe om formattering als syntax te gebruiken vind ik niet verkeerd.

[RayNbow]

* RayNbow vindt het een stuk logischer hoe Haskell puntkomma's invoegt...

[mux]

Tsja, het is misschien onintuitief als je C gewend bent, maar als je gewoon de regels volgt (en come on, elke programmeertaal heeft vage syntaxregels) en kent, is javascript een ongelooflijk wendbare taal, met extragratis ultramakkelijke (human/machine) interfacebouwer erbij.

IMO wordt javascript ook zwaar onderschat, het wordt als kinderspeelgoed gezien terwijl het op veel plekken beter gedefinieerd is (en nageleefd wordt) dan andere talen. De ECMAScript-spec is ook een van de beter leesbare. En het is uiteraard een scripttaal, met alle compilerloze/prototyping-voordelen van dien (oké, en alle snelheids- en niet-low-levelnadelen).

* mux rent weg, voelt dat er nu een flamewar begint

[FragFrog]

Het moment waarop ik JS serieus ga nemen als taal is zodra ze eindelijk een keer een fatsoenlijke manier inbakken om classes te definieren.

[Amras]

Misschien hap ik een beetje hoor, maar er zitten geen classes in Javascript omdat het een prototype language is, oftewel: je maakt een nieuw object door een oud object als prototype te gebruiken en die eventueel uit te breiden.

[mux]

Javascript is net Windows:

In Windows is alles een window
In Javascript is alles een prototype!

[.oisyn]

Soultaker schreef op maandag 05 juli 2010 @ 04:15:
[...]

Mwoah, ik vind in ieder geval Go behoorlijk C-like. En in Python kan ik precies dezelfde misleidende code schrijven:

Python:

def func():
  return 123
  + 456

Dat returnt 579 in Python . Als ik je opmerking van een stukje verderop mag geloven (die ik straks quote) niet.

Maar daar staat tegenover dat de code zelf simpeler kan worden.

Waarom wordt de code simpeler als je allerlei vage regels opneemt die bijna niemand exact weet?

Doe dat dan ook niet.

Oh please.

(en in Python móet je) haakjes toevoegen als je een expressie wil schrijven die meerdere regels beslaat.

Dat is goede syntax. Dat kan niet fout gaan. Daarmee kun je niemand op het verkeerde been zetten.

Overigens heb ik nog nooit de neiging gehad om code te schrijven zoals je die als voorbeeld opvoert, ook niet in C.

Welke neigingen jij hebt is irrelevant. Daarnaast weet ik wel een voorbeeld waarbij ik een dergelijke regel (die was uiteraard een stuk langer) wel zo heb opgeschreven, maar ook dat is irrelevant.

Elke taal heeft syntactische regels waar je je aan moet houden. Ik klaag ook niet dat ik in C mijn statements en declaraties met puntkomma's moet afsluiten.

Dat is een simpele regel

Of dat ik in C++ een spatie na de > van een geneste template parameter moet zetten.

Die regel bestaat niet meer

Als de regels maar logisch en enigzins praktisch zijn, vind ik het best.

Exact, en bij Javascript zijn ze dat niet. Go ken ik overigens verder niet goed genoeg, als die ongeveer hetzelfde doen als JS vind ik dat ook nergens over gaan.

ssj3gohan schreef op maandag 05 juli 2010 @ 08:25:
Tsja, het is misschien onintuitief als je C gewend bent, maar als je gewoon de regels volgt (en come on, elke programmeertaal heeft vage syntaxregels) en kent, is javascript een ongelooflijk wendbare taal, met extragratis ultramakkelijke (human/machine) interfacebouwer erbij.

Het punt is dat Javascript's regels ten eerste niet direct intuitief zijn, en ten tweede geen enkel praktisch nut dienen. Regels in een programmeertaal moeten zo simpel mogelijk zijn zodat iedereen ze snel kan begrijpen en mogelijke fouten geminimaliseerd worden. En die regels aanpassen resulteert niet in het feit dat Javascript dan ineens geen wendbare taal meer is. Overigens begon ik deze discussie geloof ik met de opmerking dat ik JS een mooie taal vond.

ssj3gohan schreef op maandag 05 juli 2010 @ 10:37:
Javascript is net Windows:

In Windows is alles een window
In Javascript is alles een prototype!

Beide statements zijn pertinent onwaar.

[ Voor 4% gewijzigd door .oisyn op 05-07-2010 11:21 ]

[mux]

.oisyn schreef op maandag 05 juli 2010 @ 11:20:
[...]

Het punt is dat Javascript's regels ten eerste niet direct intuitief zijn, en ten tweede geen enkel praktisch nut dienen. Regels in een programmeertaal moeten zo simpel mogelijk zijn zodat iedereen ze snel kan begrijpen en mogelijke fouten geminimaliseerd worden. En die regels aanpassen resulteert niet in het feit dat Javascript dan ineens geen wendbare taal meer is.

Dat klopt natuurlijk. Wie weet waarom ze het zo hebben geformuleerd...

Overigens begon ik deze discussie geloof ik met de opmerking dat ik JS een mooie taal vond.

Ik beweerde ook niet het omgekeerde (over jou).

Beide statements zijn pertinent onwaar.

Pf... Je gaat me niet eens verbeteren naar de manier waarop ik het bedoelde, gewoon zeggen dat ze onwaar zijn? Saai hoor.

[FragFrog]

Amras schreef op maandag 05 juli 2010 @ 09:59:
Misschien hap ik een beetje hoor, maar er zitten geen classes in Javascript omdat het een prototype language is, oftewel: je maakt een nieuw object door een oud object als prototype te gebruiken en die eventueel uit te breiden.

*hap* *hap*

Maar even serieus, ben ik de enige die dat geneuzel met prototypes een onduidelijke bende vindt?

Ow, en @ hierboven:

All generalisations are wrong!

[.oisyn]

ssj3gohan schreef op maandag 05 juli 2010 @ 11:28:
Pf... Je gaat me niet eens verbeteren naar de manier waarop ik het bedoelde, gewoon zeggen dat ze onwaar zijn? Saai hoor.

Klopt, moet je voortaan maar iets langer nadenken voordat je een niet kloppend statement plaatst. Ik kan je nu wel verbeteren waarop jij zegt "ja dat bedoelde ik ook", maar daar schieten we ook niets mee op

FragFrog schreef op maandag 05 juli 2010 @ 11:31:
Maar even serieus, ben ik de enige die dat geneuzel met prototypes een onduidelijke bende vindt?

Op zich niet. Het is allemaal wat low-level, JS heeft imho wat syntactische suiker nodig om er wat makkelijker mee te werken.

[ Voor 27% gewijzigd door .oisyn op 05-07-2010 11:39 ]

[Amras]

FragFrog schreef op maandag 05 juli 2010 @ 11:31:
[...]

*hap* *hap*

Maar even serieus, ben ik de enige die dat geneuzel met prototypes een onduidelijke bende vindt?

Tja, het is even wat anders als je gewend bent met classes te werken, maar de presentaties van bijv. Crockford zijn erg verhelderend en interessant. Toch moet ik toegeven dat ik regelmatig even op moet zoeken hoe bepaalde dingen ook alweer werken; waarschijnlijk omdat ik het niet zo vaak gebruik en doorgaans met C# bezig ben.

[Haan]

Is het eindelijk weer eens wat koeler buiten, gaan de verhitte discussies hier weer verder
* Haan neemt nog een bakkie

[mux]

FragFrog schreef op maandag 05 juli 2010 @ 11:31:
[...]


Ow, en @ hierboven:

[...]

Het is ook gewoon té leuk om .oisyn boos te maken. Eerst was ik bang van hem, maar na verloop van tijd merk je dat hij maar een robot (chatbot? Erg goed geprogrammeerd, dat zal crisp's werk zijn) op het forum is, waar je plezier mee kunt hebben.

[serieus] genoeg mensen doen niet hun best om vrij ingewikkelde denkwijzen hier uit te leggen, dan mag ik toch ook wel in een one-linertje impliceren hoe de ontwerpbeslissing van prototypes in javascript vergelijkbaar is met de ontwerpbeslissing in windows om GUI-elementen windows te maken/noemen en allemaal op die soort-van gestandaardiseerde manier te behandelen? Het is toevallig de eerste analogie die me te binnen schoot, en misschien wat vergezocht gezien het een een GUI is en het ander een scripttaal, maar dannog... Wil al helemaal niet zeggen dat ik er niet over heb nagedacht, noch dat ik al het denkwerk voor jullie moet doen.

[Sebazzz]

Ik dacht dat alleen PHP tot lange discussies leidde

[roy-t]

ssj3gohan schreef op maandag 05 juli 2010 @ 11:55:
[...]


Het is ook gewoon té leuk om .oisyn boos te maken. Eerst was ik bang van hem, maar na verloop van tijd merk je dat hij maar een robot (chatbot? Erg goed geprogrammeerd, dat zal crisp's werk zijn) op het forum is, waar je plezier mee kunt hebben.

[serieus] genoeg mensen doen niet hun best om vrij ingewikkelde denkwijzen hier uit te leggen, dan mag ik toch ook wel in een one-linertje impliceren hoe de ontwerpbeslissing van prototypes in javascript vergelijkbaar is met de ontwerpbeslissing in windows om GUI-elementen windows te maken/noemen en allemaal op die soort-van gestandaardiseerde manier te behandelen? Het is toevallig de eerste analogie die me te binnen schoot, en misschien wat vergezocht gezien het een een GUI is en het ander een scripttaal, maar dannog... Wil al helemaal niet zeggen dat ik er niet over heb nagedacht, noch dat ik al het denkwerk voor jullie moet doen.

Hoe kunnen we hier nu zien dat je er lang over nagedacht heb als je slechts je one liner plaatst

[Exirion]

Sebazzz schreef op maandag 05 juli 2010 @ 12:09:
Ik dacht dat alleen PHP tot lange discussies leidde

Wil je dat woord niet meer noemen

[Soultaker]

.oisyn schreef op maandag 05 juli 2010 @ 11:20:
Dat returnt 579 in Python . Als ik je opmerking van een stukje verderop mag geloven (die ik straks quote) niet.

Nee, dat returnt dus 123, door een soortgelijke verwarring als je signaleerde in JS (maar inderdaad niet precies hetzelfde omdat vergelijkbare code in JS wel 579 zou returnen).

Waarom wordt de code simpeler als je allerlei vage regels opneemt die bijna niemand exact weet?

Het punt is dat je consistente formattering stimuleert en tegelijkertijd de visuele dichtheid van de code verlaagd; beiden dragen bij aan de leesbaarheid. Programmeer je liever in C# of in VB.NET? Schrijf je liever { en } of BEGIN en END? Lichte syntax is fijn; het is niet essentieel, maar ook niet insignificant.

Jouw probleem is dat je weigert om de formatting te zien als onderdeel van de syntax, wat het in talen als JavaScript, Python en Go gewoon wel is. Als ik C code schrijf als:

C:

int x = 123; +  456;

Dan vind je het ook vanzelfsprekend dat hier twee losse statements staan. Wie dat niet snel inziet, moet meer oefenen om C's syntax onder de knie te krijgen. Op dezelfde manier moet je enigzins oefenen om de whitespace-regels in Python, Go of JavaScript te begrijpen en intuïtief te kunnen lezen.

Ook in C kun je trouwens ontzettend misleidende code produceren (per ongeluk een puntkomma achter de conditie van een if- of while-statement zetten bijvoorbeeld) waarin de fout moeilijk te spotten is, juist als je indenting niet overeenkomt met hoe de code geparset wordt. In Python zijn zulke fouten simpelweg onmogelijk vanwege de formattering-als-syntax.

(Re: C++ whitespace tussen >'s in template parameters) Die regel bestaat niet meer

Wat, wil je zeggen dat C++0x al geratificeerd is? De compiler die ik dagelijks gebruik vereist die whitespace wel, en ik vermoet dat dat geldt voor 90% van mensen die de afgelopen 25 jaar C++ gebruikt hebben. En nu we het daar toch over hebben, C++ heeft heel wat meer ingewikkelde constructies en rare pitfalls dan JavaScript. Daar weet je zelf nog meer van dan ik, al zul je er in de praktijk minder last van hebben omdat je gewoon veel meer ervaring met (de geavanceerde features van) C++ hebt dan (blijkbaar) met JavaScript.

Exact, en bij Javascript zijn ze dat niet. Go ken ik overigens verder niet goed genoeg, als die ongeveer hetzelfde doen als JS vind ik dat ook nergens over gaan.

Go is een stuk simpeler (net als Python trouwens). Ik geef toe dat JavaScript nogal complex is, wat jammer is, maar dat betekent niet dat het principe verkeerd is. Maar ook JavaScript's regels leiden (bij mij tenminste) in de praktijk zelden tot problemen.

[.oisyn]

Soultaker schreef op maandag 05 juli 2010 @ 13:33:
[...]

Nee, dat returnt dus 123, door een soortgelijke verwarring als je signaleerde in JS (maar inderdaad niet precies hetzelfde omdat vergelijkbare code in JS wel 579 zou returnen).

Geen verwarring. Ik zie een enter, dus het statement is ten einde. Simpele regel.

Het punt is dat je consistente formattering stimuleert en tegelijkertijd de visuele dichtheid van de code verlaagd; beiden dragen bij aan de leesbaarheid. Programmeer je liever in C# of in VB.NET? Schrijf je liever { en } of BEGIN en END? Lichte syntax is fijn; het is niet essentieel, maar ook niet insignificant.

Dat is het hele punt niet, want javascript doet niets van zulks. Javascript forceert helemaal geen enters en indentatie. En door een C-achtige syntax te gebruiken verwacht je dat een enter niets doet, net als in vrijwel alle C-achtige talen zoals C, C++, Java, PHP, C#, ...

Jouw probleem is dat je weigert om de formatting te zien als onderdeel van de syntax, wat het in talen als JavaScript, Python en Go gewoon wel is.

Grote onzin. Ik vind talen waarin formatting van belang is weldegelijk nut hebben. Ik vind de regels van javascript alleen onhandig. Hoe moeilijk is dat nou om te accepteren? Waarom doe je alsof ik een C++ zealot ben die niet goed over dingen na kan denken en daarom alles wat niet C++ is afbrandt? Misschien moet je m'n posthistory eens door gaan lezen, dan zul je zien dat ik op C++ net zo goed dingen aan te merken heb.

Als ik C code schrijf als:

C:

int x = 123; +  456;

Dan vind je het ook vanzelfsprekend dat hier twee losse statements staan.

En de regels zijn wat dat betreft ook simpel. Een \n is een whitespace en doet verder niets. Een ; markeert satement-einde. En niet "in het ene geval betekent een enter niets, maar in het andere geval weer wel". Python heeft het wat dat betreft ook goed voor elkaar. Een enter is altijd statement-einde, tenzij het duidelijk is dat de expressie nog niet klaar is.

Ook in C kun je trouwens ontzettend misleidende code produceren (per ongeluk een puntkomma achter de conditie van een if- of while-statement zetten bijvoorbeeld) waarin de fout moeilijk te spotten is, juist als je indenting niet overeenkomt met hoe de code geparset wordt. In Python zijn zulke fouten simpelweg onmogelijk vanwege de formattering-als-syntax.

En dat juich ik Python ook toe

Wat, wil je zeggen dat C++0x al geratificeerd is?

Nee, maar dat de gangbare compilers die regel inmiddels niet meer kennen (GCC, MSVC++ vanaf 2008, Intel C++, Comeau), en dat dit een bekende issue is waarvan de mensen erachter wat aan gedaan hebben.

En nu we het daar toch over hebben, C++ heeft heel wat meer ingewikkelde constructies en rare pitfalls dan JavaScript. Daar weet je zelf nog meer van dan ik, al zul je er in de praktijk minder last van hebben omdat je gewoon veel meer ervaring met (de geavanceerde features van) C++ hebt dan (blijkbaar) met JavaScript.

Wat probeer je hier nu eigenlijk mee aan te tonen? Alsof ik beweer dat C++ perfect is. Ja, ook C++ kent vervelende regels en ja die had ik liever ook niet gezien. Ik vind het een beetje een raar argument eigenlijk. "JS doet dit. -Ja maar C++ doet zus en zo". Wat is dit, een wedstrijd moddergooien?

Ik geef toe dat JavaScript nogal complex is, wat jammer is, maar dat betekent niet dat het principe verkeerd is.

Ik had het ook niet over het principe, ik had het over javascript - jij bent zelf degene die begon over het principe. Feit is dus dat je het al die tijd met me eens bent maar alleen dacht dat ik ten strijde trok tegen het formatting in de syntax in z'n algemeenheid, wat geenszins het geval is.

[ Voor 114% gewijzigd door .oisyn op 05-07-2010 17:13 ]

[Megamind]

Ik moet een website gaan verbouwen, teminste dat doe ik niet, ik stuur het alleen aan.

Nu heb ik een lijst met wijzigingen liggen, en die wil ik het liefst met een screenshot duidelijk maken, dat is wel zo makkelijk voor de designers.

Maar nu zit ik alles met PS erin te vrotten, zijn daar geen goede tools voor?

[mux]

.oisyn schreef op maandag 05 juli 2010 @ 13:55:
Een enter is altijd statement-einde, tenzij het duidelijk is dat de expressie nog niet klaar is.

Dat is in JS precies hetzelfde, maar met een andere interpretatie van 'tenzij het [voor de interpreter] duidelijk is...' . Als je weet hoe het werkt - namelijk: de interpreter kijkt één token vooruit en kijkt of het nog past - is het zelfs erg gemakkelijk te begrijpen. Niet als je een andere taal gewend bent en voor de eerste keer naar JS kijkt, maar wel zodra je een keer de basics hebt doorgelezen. Je moet toch van elke taal eerst de basics doorgronden voor je het productief kunt gebruiken?

Maar, we praten er nu heel lang en moeilijk over maar: boeit het echt zoveel? Het is IMO geen groot struikelblok bij JS schrijven, net als de meeste andere syntaxraarheden in andere talen.

[Sebazzz]

Megamind schreef op maandag 05 juli 2010 @ 14:42:
Maar nu zit ik alles met PS erin te vrotten, zijn daar geen goede tools voor?

Een willekeurig prototyping tool misschien?

Exirion schreef op maandag 05 juli 2010 @ 12:31:
[...]

Wil je dat woord niet meer noemen

Sorry

[ Voor 26% gewijzigd door Sebazzz op 05-07-2010 15:15 ]

[roy-t]

Megamind: ik kan balsamiq mockup aanraden, probeer gewoon de gratis online tool en exporteer dan naar PNG .

Hmm, de BADA SDK van Samsung is nog niet erg volwassen, ik krijg met geen mogelijkheid voor elkaar dat het contacts scherm getoond wordt, en er is echt geen documentatie over te vinden hoe dat moet. Nu al een paar uur een vraag openstaan op het officiele forum. Hoop dat het snel tijd wordt om op te staan in Korea (ik denk dat daar de devs wonen ).

[.oisyn]

ssj3gohan schreef op maandag 05 juli 2010 @ 15:00:
Als je weet hoe het werkt - namelijk: de interpreter kijkt één token vooruit en kijkt of het nog past - is het zelfs erg gemakkelijk te begrijpen.

Ja, duh. Als je weet dat PHP een string naar int converteert als je vergelijkt met een andere int dan is dat ook makkelijk te begrijpen. Wil nog niet zeggen dat dat een logische intuitieve regel is (waaruit volgt dat "aap" == 0 evalueert naar true).

[ Voor 8% gewijzigd door .oisyn op 05-07-2010 17:56 ]

[Laurens-R]

Megamind schreef op maandag 05 juli 2010 @ 14:42:
Ik moet een website gaan verbouwen, teminste dat doe ik niet, ik stuur het alleen aan.

Nu heb ik een lijst met wijzigingen liggen, en die wil ik het liefst met een screenshot duidelijk maken, dat is wel zo makkelijk voor de designers.

Maar nu zit ik alles met PS erin te vrotten, zijn daar geen goede tools voor?

als je bereid bent te betalen: Expression Blend met sketchflow

[roy-t]

.oisyn schreef op maandag 05 juli 2010 @ 16:55:
[...]

...dat PHP een string naar int converteert als je vergelijkt met een andere int

[Soultaker]

.oisyn schreef op maandag 05 juli 2010 @ 13:55:
Waarom doe je alsof ik een C++ zealot ben die niet goed over dingen na kan denken en daarom alles wat niet C++ is afbrandt?

Dat zeg ik niet en wilde ik ook helemaal niet suggereren! Ik wilde alleen aangeven dat er wel talen zijn met aanzienlijk complexere en tegen-intuïtievere syntactische constructies, die desondanks volop en met succes gebruikt worden. Dan ligt C++ voor de hand. En vergeleken daarbij is JavaScript nog steeds een pareltje, ondanks wat rariteiten.

Ik had het ook niet over het principe, ik had het over javascript - jij bent zelf degene die begon over het principe.

Ja, ik had "die hele semicolon insertion gaat nergens over" inderdaad ruim opgevat (want laten we wel zijn, dat is niet echt een genuanceerde, specifieke kritiek). Persoonlijk vind ik nog steeds dat semicolon insertion in het algemeen en in JavaScript in het bijzonder wél nuttig is, hoewel ik het met je eens ben dat de uitwerking eigenlijk te ingewikkeld gemaakt is. Wat dat betreft lijken we het inderdaad wel min of meer eens te zijn.

Mooi, next topic.

[.oisyn]

Jeej grouphug

[Exirion]

Volgende rel

[Matis]

Exirion schreef op maandag 05 juli 2010 @ 18:47:
Volgende rel

Vooruit, vandaag een projectje opgepakt van een collega.

Java GUI's via source editen, yuck

[Alex)]

Mooie gelegenheid om het om te bouwen naar WPF / Silverlight.

XAML

[Snake]

Matis schreef op maandag 05 juli 2010 @ 18:52:
[...]

Vooruit, vandaag een projectje opgepakt van een collega.

Java GUI's via source editen, yuck

GUI's via code algemeen, zoals Winforms dat is kut.

Maar goed, dat was vroeger nu eenmaal de standaard.

1 ding wat me bij GUI's tegen de borst stoot, en dan heb ik het over HTML is dat ze niet 100% correct moeten zijn. Bij mij was dat niet waar. 100% correct ofwel error. Want met al die vergevingsgezindheid tegenwoordig is het slecht gesteld met de websites.

Alex) schreef op maandag 05 juli 2010 @ 18:57:
Mooie gelegenheid om het om te bouwen naar WPF / Silverlight.

XAML

Couldn't agree more.

[Matis]

Alex) schreef op maandag 05 juli 2010 @ 18:57:
Mooie gelegenheid om het om te bouwen naar WPF / Silverlight.

XAML

Waarschijnlijk wel, ware het niet dat ik daar geen zeggeschap over heb

Het lastige is gewoon dat je een JFrame hebt, met daarin een TabbedPane, met daarin JPanels en JScrollPanes met daarin weer BorderLayout's, JLists enzo. Ze hebben ook allemaal mouselisteners en change-events. En die moet je ook allemaal weer aparte afmetingen opgeven. Ergens een knopje bijzetten was geen optie.
Misschien heeft dat er mee te maken dat ik tot op heden nog geen complexe desktop programma's/applicaties heb gezien en/of ermee heb mogen werken (ben pas net afgestudeerd), maar graven in andermans code (ondanks goede comments en doxygen) is toch best lastig

Ik heb overwogen om een GUI-sleur-en-pleur-IDE te gebruiken, maar die kan niet overweg met de dynamische vormen van onze applicatie.

Enniehoe, morgen nog een beetje hacken; Ik begin nu de werking van de applicatie in te zien

[Exirion]

Snake schreef op maandag 05 juli 2010 @ 19:03:
GUI's via code algemeen, zoals Winforms dat is kut.

Voor de iPhone is dat nogsteeds de enige goeie manier. Het gebruik van Interface Builder is zo omslachtig dat je de relatief eenvoudige opbouw van iPhone views het beste met code kunt doen. Kost minder werk/code en je snapt beter wat er gebeurt. Wat dat betreft kan Apple nog wel wat leren van goeie RAD tools.

[CodeCaster]

Wat is er nou zo mooi aan XAML / WPF dan?

Ik moet toegeven er nog niet heel veel tijd aan te hebben besteed, maar applicaties die gerenderd worden in WPF hebben bij mij altijd een onaf gevoel, zeker door het knipperen bij het verplaatsen en resizen van vensters (op meerdere systemen last van), en UI's die ermee (kunnen) worden gemaakt doen al snel erg druk en flashy aan. Niet prettig voor applicaties die langdurig gebruikt moeten worden. En die waas Alles moet zo vloeiend en smooth mogelijk, ik heb na een dag het gevoel scheel te kijken.

En daarnaast, XAML met het handje bewerken is nog zenuwslopender dan met die properties-box van Visual Studio.

[Verwijderd]

XAML via sleur en pleur moet je dan ook met een andere mindset aanpakken dan met winforms. Zolang je in het achterhoofd houdt dat relatieve en absolute positionering veel uitmaakt (zoals in html design) kan je er heel leuke dingen mee doen.

[Megamind]

Exirion schreef op maandag 05 juli 2010 @ 19:13:
[...]

Voor de iPhone is dat nogsteeds de enige goeie manier. Het gebruik van Interface Builder is zo omslachtig dat je de relatief eenvoudige opbouw van iPhone views het beste met code kunt doen. Kost minder werk/code en je snapt beter wat er gebeurt. Wat dat betreft kan Apple nog wel wat leren van goeie RAD tools.

Met Android is het niet veel beter gesteld

[R4gnax]

Snake schreef op maandag 05 juli 2010 @ 19:03:
[...]

GUI's via code algemeen, zoals Winforms dat is kut.

.NET Winforms? De designer interface van Visual Studio is toch niet slecht te noemen.

Bedoel je niet GUIs via WinAPI of MFC?

[CodeCaster]

R4gnax schreef op maandag 05 juli 2010 @ 20:33:
[...]


.NET Winforms? De designer interface van Visual Studio is toch niet slecht te noemen.

Bedoel je niet GUIs via WinAPI of MFC?

Hij zegt toch GUI's via code

C#:

this.OKButton = new System.Windows.Forms.Button();
this.SuspendLayout();
// 
// OKButton
// 
this.OKButton.Location = new System.Drawing.Point(73, 75);
this.OKButton.Name = "OKButton";
this.OKButton.Size = new System.Drawing.Size(75, 23);
this.OKButton.TabIndex = 0;
this.OKButton.Text = "OK";
this.OKButton.UseVisualStyleBackColor = true;
this.Controls.Add(this.OKButton);
this.ResumeLayout(false);

Ik vind het nog wel meevallen eigenlijk.

Verwijderd schreef op maandag 05 juli 2010 @ 19:32:
XAML via sleur en pleur moet je dan ook met een andere mindset aanpakken dan met winforms. Zolang je in het achterhoofd houdt dat relatieve en absolute positionering veel uitmaakt (zoals in html design) kan je er heel leuke dingen mee doen.

Dat is het XAML-gedeelte ja En ik ben niet voor niets niet doorgegaan met server- danwel clientside webdevelopment. Ik háát Markup Language.

[ Voor 28% gewijzigd door CodeCaster op 05-07-2010 20:38 ]

[Sebazzz]

En die waas Alles moet zo vloeiend en smooth mogelijk, ik heb na een dag het gevoel scheel te kijken.

Dat komt door de Device Independend Pixel, maar dat is opgelost in .NET 4.

[CoolGamer]

CodeCaster schreef op maandag 05 juli 2010 @ 20:36:
[...]

Hij zegt toch GUI's via code

C#:

this.OKButton = new System.Windows.Forms.Button();
this.SuspendLayout();
// 
// OKButton
// 
this.OKButton.Location = new System.Drawing.Point(73, 75);
this.OKButton.Name = "OKButton";
this.OKButton.Size = new System.Drawing.Size(75, 23);
this.OKButton.TabIndex = 0;
this.OKButton.Text = "OK";
this.OKButton.UseVisualStyleBackColor = true;
this.Controls.Add(this.OKButton);
this.ResumeLayout(false);

Ik vind het nog wel meevallen eigenlijk.

Grootste nadeel is dat je niet gelijk kan zien wat het resultaat is van de verandering aan de code die je hebt gedaan. Zo zal je bijvoorbeeld in code niet snel zien of twee objecten overlappen. Om het makkelijker te maken zou je van te voren een schets van kunnen maken of iets dergelijke. Maar direct in een grafische editor is toch makkelijker.

[FragFrog]

Snake schreef op maandag 05 juli 2010 @ 19:03:
Want met al die vergevingsgezindheid tegenwoordig is het slecht gesteld met de websites.

Tegenwoordig? Onder welke steen zat jij ten tijde van IE4 / IE5?

Sterker nog, mijn eigen website heb ik van het weekend volledig herschreven (oude ding stelde weinig voor) en om wat leuke schaduw en border-radius effecten werkend te krijgen in Firefox moet ik wel zaken als -moz-border-radius gebruiken - en die valideren niet. Templates zelf zijn prima strict xhtml1.1, maar voor de css moet ik wel browser-specifieke tags gebruiken hier en daar domweg omdat ze te weinig accepteren (alsin, valide CSS3 tags werken in de ene browser wel en in de andere weer niet). Suf gedoe, gelukkig herschrijf ik de boel doorgaans maar een keer per vijf jaar ofzo dus kan er weer even tegenaan

Om in te haken @ hierboven: voor mijn allereerste GUI java project moet ik ook bekennen Netbeans' grafische editor gepakt te hebben. JPanels zijn leuk maar je zit inderdaad al vrij snel vijf, zes lagen diep te nesten, dan wordt de code vrij complex. Then again, met HTML heb ik daar weer geen moeite mee, kwestie van wennen gok ik.

[ Voor 15% gewijzigd door FragFrog op 06-07-2010 01:52 ]

[AtleX]

FragFrog schreef op dinsdag 06 juli 2010 @ 01:49:
Templates zelf zijn prima strict xhtml1.1, tagsoup

Content-Type: text/html; charset=utf-8

[Sebazzz]

Dacht precies hetzelfde ja Nu is het helemaal niet moeilijk om wél het juiste content type mee te sturen, de browsers die XHTML eten geven wel aan dat ze application/xhtml+xml accepteren en dan kan je het gewoon met dat MIME type opsturen.

[YopY]

Toch heb ik niet het idee dat HTML en CSS nu zo geweldig zijn voor gui ontwerp. Word tijd voor een Unified Markup Language waar je stijl, structuur en opmaak in (ongeveer) één taal kunt doen (wel gescheiden natuurlijk), waarbij je meer eigenschappen en grafische elementen kunt stylen dan met HTML / CSS alleen.

Ik bedoel... HTML om inhoud weer te geven, CSS om te stylen, en JS voor gedrag en overgang(en) / animaties... moet beter kunnen.

Element somediv;
somediv.border = {style:solid, width:1px, color:black};
somediv.onclick(function() { doeIets() });

veel te vroeg, laat maar ;p.

[AtleX]

Sebazzz schreef op dinsdag 06 juli 2010 @ 08:17:
Dacht precies hetzelfde ja Nu is het helemaal niet moeilijk om wél het juiste content type mee te sturen, de browsers die XHTML eten geven wel aan dat ze application/xhtml+xml accepteren en dan kan je het gewoon met dat MIME type opsturen.

Afaik mag XHTML 1.1 strict alleen met dat mime-type verstuurd worden, dus je kan niet 'gewoon' even text/html gaan sturen als een UA het niet meer snapt.

[Sebazzz]

AtleX schreef op dinsdag 06 juli 2010 @ 08:32:
[...]

Afaik mag XHTML 1.1 strict alleen met dat mime-type verstuurd worden, dus je kan niet 'gewoon' even text/html gaan sturen als een UA het niet meer snapt.

Nee maar het is de beste fall-back die je hebt. Zeker voor ouderwetse browsers zoals IE8/IE7/IE6.

[mux]

YopY: je bedoelt dat we de ideale taal even moeten uitvinden

In principe is HTML+CSS+JS best een aardige scheiding van kerk en staat, theoretisch. In de praktijk is alles een groot rommeltje, maar het is allicht beter (voor dit doel) dan LaTeX etc.

[YopY]

ssj3gohan schreef op dinsdag 06 juli 2010 @ 08:35:
YopY: je bedoelt dat we de ideale taal even moeten uitvinden

Community project? . Helaas is ideaal niet haalbaar, zullen altijd mensen zijn die het er niet mee eens zijn.

In principe is HTML+CSS+JS best een aardige scheiding van kerk en staat, theoretisch. In de praktijk is alles een groot rommeltje, maar het is allicht beter (voor dit doel) dan LaTeX etc.

Ja, eigenlijk wel, HTML en CSS zelf zijn, als je het een beetje netjes en zorgvuldig doet, best wel goed mee te werken. Ik heb alleen zo'n hekel aan Javascript, :x. Misschien dat die tool van Google die Java code converteert naar Javascript iets voor mij.

Ik heb ook wel eens (voor een onderzoekje die ik binnenkort eens zou moeten herhalen tbv een blogreeks of discussietopics hiero) wat onderzoek gedaan naar webframeworks, één ding wat daar opviel was dat er in Ruby een soort van template-taal is waar je de HTML genereert adhv de programmeertaal zelf. Zoiets zou potentie hebben, maar eigenlijk alleen praktisch als je meerdere uitvoerformaten hebt (html, text, xml, etc). En daar hebben ze natuurlijk ook XML + XSL voor uitgevonden.

...maar voor zover ik weet is er niet echt een soort van taal waarmee je operaties die je op XML uitvoert 1 op 1 kunt converteren naar dezelfde operaties op HTML. Zou misschien een 'next-gen'-iets zijn - je definieert een soort van applicatie in XML en een soort van Javascript of andere programmeertaal, en met next-gen XSL kun je dat converteren naar een HTML webapplicatie (op meerdere niveaus van geavanceerdheid), een desktop-applicatie, of iets voor telefoons.

...oké, dat kan nu al met gewoon html.

Nu ik toch zit te ranten, het lijkt mij nog steeds dat je tegenwoordig beter een goede webapplicatie kunt bouwen dan een website en een aparte mobiele app voor de diverse platformen. Natuurlijk ben je dan wel enigsinds beperkt in je mogelijkheden door wat er mogelijk is met HTML, maar ik geloof zo dat dit in de toekomst zal verbeteren.

...oh wacht, ActiveX. Je kunt al dingen doen als je hele OS upgraden via een website, .

[AtleX]

Apps zijn stom. Waarom zou je tig platformen met losse apps gaan ondersteunen als je ook gewoon 1 mobiele website kunt maken die vrijwel op elke telefoon/MID werkt? Met apps bereik je alleen maar een gigantische versplintering en verwaarlozing van platformen, en da's geen richting die ik het mobiele internet graag op zie gaan.

[ Voor 33% gewijzigd door AtleX op 06-07-2010 10:32 ]

[Kalentum]

YopY schreef op dinsdag 06 juli 2010 @ 10:23:
...maar voor zover ik weet is er niet echt een soort van taal waarmee je operaties die je op XML uitvoert 1 op 1 kunt converteren naar dezelfde operaties op HTML. Zou misschien een 'next-gen'-iets zijn - je definieert een soort van applicatie in XML en een soort van Javascript of andere programmeertaal, en met next-gen XSL kun je dat converteren naar een HTML webapplicatie (op meerdere niveaus van geavanceerdheid), een desktop-applicatie, of iets voor telefoons.

Misschien komt Titanium in de buurt?

http://www.appcelerator.c...-application-development/

[Exirion]

AtleX schreef op dinsdag 06 juli 2010 @ 10:26:
Apps zijn stom. Waarom zou je tig platformen met losse apps gaan ondersteunen als je ook gewoon 1 mobiele website kunt maken die vrijwel op elke telefoon/MID werkt? Met apps bereik je alleen maar een gigantische versplintering en verwaarlozing van platformen, en da's geen richting die ik het mobiele internet graag op zie gaan.

Hoewel software in de loop de tijd steeds platformonafhankerlijker en meer portable is geworden, is volledig cross-platform software nogsteeds een utopie. Je offert vrijwel altijd performance op, dus over verwaarlozing van platformen gesproken...... Voor een simpel appje is performance niet zo'n issue, maar probeer bijvoorbeeld maar 's image recognition te doen voor bar codes in een Java omgeving op een telefoon

[AtleX]

Ik gok dat 80% van de apps gaat over het tonen van info die ook al op een site zichtbaar is. Buienrader? Buienradar.mobi werkt prima. Hyves app? Hyves heeft een vrij aardige mobile site. Wikipedia? m.wikipedia.org werkt hier uitstekend. Dan vind ik het zonde als sites ervoor kiezen om wel een app te maken voor 1 (of 2, of 3) platformen maar de rest negeren en vaak ook geen of een slechte mobiele site aanbieden.

[dev10]

AtleX schreef op dinsdag 06 juli 2010 @ 10:48:
Hyves app? Hyves heeft een vrij aardige mobile site.

Sterker nog, ik gebruik op m'n iPhone de Hyves website veel vaker dan de Hyves app, omdat ik met de website profielinformatie kan bekijken. (Leeftijd, geslacht, interesses enzo.) Met de Hyves app kan dat niet.

[Exirion]

AtleX schreef op dinsdag 06 juli 2010 @ 10:48:
Ik gok dat 80% van de apps gaat over het tonen van info die ook al op een site zichtbaar is.

De 20% die onmogelijk wordt vind ik nog altijd een categorie die je niet kunt verwaarlozen. Bovendien is Java altijd teveel geidealiseerd, want op verschillende telefoons heb je altijd weer met afwijkend gedrag te maken. Je zou kunnen stellen dat ze er wat dat betreft een beetje van teruggekomen zijn. En gelukkig maar, wat mij betreft.

[Janoz]

Op zich ben ik het er maar gedeeltelijk mee eens. In principe zou het startpunt inderdaad een goed werkende mobiele site moeten zijn. Een app bied echter wel wat extra mogelijkheden.

-De app kan een stuk responsiever.
-Beter overeenkomen met de widget structuur en GUI guidlines van het platform.
-Push mogelijkheden

Buienradar is typisch zo'n applicatie die die meerwaarde niet biedt. Daarvoor kun je beter naar de site gaan. Maar de android app van de Rabobank werkt gewoon een stuk prettiger dan de mobiel bankieren site. Ook de tvgids.tv app werkt veel sneller dan het surfen over de website (nadeel is echter wel dat het synchroniseren niet altijd goed gaat waardoor de meerwaarde van de app wat verdwijnt). De facebook website kan nooit zo mooi integreren met mijn adresboek als de htc facebook app dat kan.

Kortom. Er is wel degelijk meerwaarde voor een app boven een mobiele website.

[YopY]

rutgerw schreef op dinsdag 06 juli 2010 @ 10:32:
Misschien komt Titanium in de buurt?

http://www.appcelerator.c...-application-development/

Plaatje ziet er veelbelovend uit, moet nog even napluizen of het ook wat is. Echter, volgens de nieuwe Apple regels mag je dit niet gebruiken voor iphone development.

(Begrijp ik overigens dat je Ruby, JS én Python moet gebruiken, of is het ruby of python? beetje vaegh.)


@apps, zolang je niet de performance en mogelijkheden hebt in HTML (en verwanten) die 'native' apps wel hebben, zul je altijd apps blijven hebben. Kun je bijvoorbeeld dmv HTML en JS bij een camera?

En Java... tsja... heeft dat voor het mobiele platform in de afgelopen vijf jaar nog wat ontwikkeling doorgemaakt?

[Sebazzz]

En Java... tsja... heeft dat voor het mobiele platform in de afgelopen vijf jaar nog wat ontwikkeling doorgemaakt?

Hoogstens Android, maar strict genomen is dat geen Java Platform. Totaal andere runtime, en maar een klein deel van het framework wordt herbruikt.

Ik kon mij altijd de hel van Java ME herinneren. Spelletjes die het op een Sony Ericsson deden deden het nooit op mijn LG Chocolate, en andersom

[Exirion]

Sebazzz schreef op dinsdag 06 juli 2010 @ 11:06:
Ik kon mij altijd de hel van Java ME herinneren. Spelletjes die het op een Sony Ericsson deden deden het nooit op mijn LG Chocolate, en andersom

Dat bedoel ik. Ze roepen nu al 15 jaar hoe geweldig Java is, maar het is gewoon nooit geworden wat door veel goden voorspeld was.

[YopY]

Sinds java 5 kan ik me ook geen echte ontwikkelingen meer bedenken die met Java gedaan zijn... Genoeg nieuwe libraries en dergelijke projecten, maar echt activiteit in de 'core' zie ik niet zoveel meer. In tegenstelling tot .NET, dat het stokje overgenomen heeft.

En Android... ach, de taal zelf en bytecode en dergelijke zijn allemaal zeer goed gedocumenteerd (meen ik te menen), dus om daar een nieuw platform op te baseren lijkt me wel goed. Op zich.

Java heeft zich over de jaren meer gericht (lijkt het) op enterprise toepassingen, en dan specifiek webapplicaties.

[Janoz]

YopY schreef op dinsdag 06 juli 2010 @ 11:32:
Java heeft zich over de jaren meer gericht (lijkt het) op enterprise toepassingen, en dan specifiek webapplicaties backend systemen.

[Sebazzz]

En Android... ach, de taal zelf en bytecode en dergelijke zijn allemaal zeer goed gedocumenteerd (meen ik te menen), dus om daar een nieuw platform op te baseren lijkt me wel goed.

Nou, bepaalde delen zijn zeer slecht gedocumenteerd. Ga maar eens een input service maken. En bij veel methoden heb je ook enkel een signature en voor de rest mag je het zelf uitzoeken. De Javadoc die er zelf bij geleverd wordt (dus voor in je IDE) is ook niet altijd super, zoek maar eens uit wat arg0, arg1, arg2 betekenen bij een methodeaanroep (eronder staat het dan weer wel beschreven, maar met de echte namen van de parameters).

Genoeg nieuwe libraries en dergelijke projecten, maar echt activiteit in de 'core' zie ik niet zoveel meer. In tegenstelling tot .NET, dat het stokje overgenomen heeft.

Ze zijn met closures bezig, maar ik heb het idee dat Java een groot oud beest is dat niet met de tijd mee wil of kan gaan. Waarom zijn negen van de tien methodes waarbij je een keuzeoptie hebt bijvoorbeeld nog steeds met een integer in plaats van een enumeration geïmplementeerd?

Backwards compatibility, vast wel, maar op het gegeven moment moet je gewoon de knoop doorhakken en dan zeggen van: Deze runtime is niet meer backwards compatible. Zoiets wat Microsoft met .NET 2 heeft gedaan (je had .NET 1.1 en .NET 2 waarbij de runtimes niet compatible waren).

[YopY]

Tsja, closures... lijkt mij echt een 'Ik Ook' feature die ze erin forceren, "omdat de anderen het ook hebben".

En het lijkt mij ook redelijk eenvoudig om de standaard library te refactoren om nieuwe taalfeatures - zoals enums - te gebruiken. Backwards compatibility is daarbij een non-argument, aangezien je gewoon een nieuwe functie die een enum gebruikt kunt gebruiken om de bestaande functie aan te roepen met een int, of vice-versa, dat de int functie een conversie doet naar de enum functie en als @deprecated aangemerkt staat (met de opmerking dat het verwijderd wordt in een volgende versie).

D'r zijn genoeg methodes om backwards compatibility te garanderen of om de overstap te versoepelen. Tijd voor Java 2.0, ga maar snijden in die API. Lijkt me met dat in het achterhoofd ook niet gek dat Google de Java API's herschreven heeft.

@Janoz, I stand corrected .

De Javadoc die er zelf bij geleverd wordt (dus voor in je IDE) is ook niet altijd super, zoek maar eens uit wat arg0, arg1, arg2 betekenen bij een methodeaanroep (eronder staat het dan weer wel beschreven, maar met de echte namen van de parameters).

Is dat niet een kwestie van je IDE goed configureren? Volgens mij kun je zo de source van de JDK eraan koppelen - het lijkt me heel sterk dat ze arg0, arg1 etc in de officiële functies gebruiken.

[Sebazzz]

Tsja, closures... lijkt mij echt een 'Ik Ook' feature die ze erin forceren, "omdat de anderen het ook hebben".

'Ik ook' of niet, ik vind het verdomde handig. Er is niets lekkerder dan gewoon someCollection.Sum(a => a.someBoolean) aan te kunnen roepen. Ik vind het heerlijk werken, closures/lamnda's zijn zeer handig. En afhankelijk van waar je het voor gebruikt Linq achtige dingen ook. Zelfs al is het maar syntactische suiker.

Is dat niet een kwestie van je IDE goed configureren? Volgens mij kun je zo de source van de JDK eraan koppelen - het lijkt me heel sterk dat ze arg0, arg1 etc in de officiële functies gebruiken.

Nou, ik heb hem juist gekoppeld. Medestudenten die Eclipse (project corruption FTW) in plaats van NetBeans gebruiken hebben ook problemen.

Backwards compatibility is daarbij een non-argument,

Dat is de enige reden dat ik kan bedenken waarom ze de boel niet hebben refactored. Ja ik kan nog wel wat bedenken, maar ik vind het zeker voor desktop en EE development niet relevant: Een kleine drop in performance. Hoewel het mij simpelweg referenties / geheugenadressen vergelijken lijkt. Maar blijkbaar niet.

[ Voor 5% gewijzigd door Sebazzz op 06-07-2010 12:33 ]

[.oisyn]

Een kleine drop in performance. Omdat in Java alles een class is, is een enum ook een class.

Valt toch wel mee? Sure, enums moeten geinstantieerd worden, maar da's maar 1 keer. Voor de rest vergelijk je gewoon referenties. Ik vind Java's enums mooier dan .Net's enums, wat eigenlijk gewoon ints zijn zoals in C/C++.

.edit: ja stiekem je post editen he

[ Voor 21% gewijzigd door .oisyn op 06-07-2010 12:34 ]

[Sebazzz]

.oisyn schreef op dinsdag 06 juli 2010 @ 12:34:
[...]

Valt toch wel mee? Sure, enums moeten geinstantieerd worden, maar da's maar 1 keer. Voor de rest vergelijk je gewoon referenties.

Dat zei ik omdat het voor bijvoorbeeld Android development afgeraden wordt, vanwege geheugengebruik maar vooral performance. Android is tot 2.2 dan wel geïnterpreteerd en niet geJIT maar het is het enige argument dat ik kan bedenken waarom enums nog niet volledig in de Java API zijn verwerkt.

Ik vind Java's enums mooier dan .Net's enums, wat eigenlijk gewoon ints zijn zoals in C/C++.

Het zijn integers ja, en dat vind ik ook wel prettig eigenlijk. Makkelijk ergens naartoe te serializen (dit is vast ook wel mogelijk met Java enums maar toch). Je moet je de vraag stellen of je wel juist bezig bent als je heel veel methodes en velden in je enum gaat hangen.
Overigens vind ik .NET enums flexibel genoeg, je kan er attributen aan hangen en extensionmethods aan hangen. Veel meer moet je imo ook niet willen.
En gek is het ook niet: C# is in principe veel meer als een C-stijl taal bedoeld terwijl het met Java niet de intentie was.

Wat ik trouwens ook mis bij Java is operator overloading. Terwijl het voor bepaalde types, zoals een String wel in de API is gehackt terwijl je het zelf niet kan definiëren.

.edit: ja stiekem je post editen he

Zoals RobIII het zegt: Ik zeg eerst iets, daarna lees ik het terug en pas ik het aan, en ik was toch eerst

[ Voor 6% gewijzigd door Sebazzz op 06-07-2010 12:45 ]

[.oisyn]

Sebazzz schreef op dinsdag 06 juli 2010 @ 12:42:
Het zijn integers ja, en dat vind ik ook wel prettig eigenlijk. Makkelijk ergens naartoe te serializen (dit is vast ook wel mogelijk met Java enums maar toch).

Java Enums zijn natuurlijk ook gewoon serializable. Ze hebben ook gewoon een int waarde, verkrijgbaar met de ordinal() method.

Je moet je de vraag stellen of je wel juist bezig bent als je heel veel methodes en velden in je enum gaat hangen.

Heb je daar ook argumenten bij? Want ik vind dat persoonlijk eerlijk gezegd onzin. Enums zijn elementen uit een eindige set, zoals bijvoorbeeld de dagen van een week. Er is niets mis mee om daar eigenschappen aan toe te kennen, zoals bijvoorbeeld de boolean of het een weekend-dag is.

En gek is het ook niet: C# is in principe veel meer als een C-stijl taal bedoeld terwijl het met Java niet de intentie was.

Sorry, maar dat gaat echt nergens over. Kom maar op met de bronnen die dat beweren . C# 4.0 is imho verder verwijderd van C of C++ dan Java dat is.

[ Voor 14% gewijzigd door .oisyn op 06-07-2010 13:08 ]

[Sebazzz]

Mijn excuus, ik wist niet dat dit ineens een Java vs C# discussie was. Ik dacht dat we het over enums hadden.

Mijn excuus, ik dacht dat ik het had over wat ik miste bij Java. (Dat liep voort uit de discussie dat de ontwikkeling niet snel ging).

Sorry, maar dat gaat echt nergens over. Kom maar op met de bronnen die dat beweren .

Ik pak mijn oude vergeelde toch nog actuele C++ boek erbij (Grand Cru). "Microsoft wil met C# een C-stijl taal maken waarin de gevaarlijke constructies zoals [...] zijn verwijderd en waarbij het ontwikkelen eenvoudiger wordt. Dit zodat het ontwikkelen van een applicatie sneller en eenvoudiger gaat."

Heb je daar ook argumenten bij? Want ik vind dat persoonlijk eerlijk gezegd onzin.

In dat geval heb ik een wedervraag: Wat wil je in hemelsnaam allemaal in Enums kwijt dat je heel veel methodes en velden gaat gebruiken? (misschien over 'heel veel' heengelezen? )

[.oisyn]

Sebazzz schreef op dinsdag 06 juli 2010 @ 13:07:
Ik pak mijn oude vergeelde toch nog actuele C++ boek erbij (Grand Cru). "Microsoft wil met C# een C-stijl taal maken waarin de gevaarlijke constructies zoals [...] zijn verwijderd en waarbij het ontwikkelen eenvoudiger wordt. Dit zodat het ontwikkelen van een applicatie sneller en eenvoudiger gaat."

Ah ja, dat is al een stuk genuanceerder dan wat jij zei, en waarom past Java niet in die filosofie?

In dat geval heb ik een wedervraag: Wat wil je in hemelsnaam allemaal in Enums kwijt dat je heel veel methodes en velden gaat gebruiken? (misschien over 'heel veel' heengelezen? )

Oh please. Het ging om de mogelijkheid om die velden op te kunnen nemen. Het verschil tussen een paar en heel veel is in die discussie totaal irrelevant.

[Snake]

Even wat anders: Windows Phone 7 ondersteund blijkbaar geen custom certificates WTF? Al die mensen die Exchange met een self signed certificate gebruiken vallen dan uit de boot. Leuk seg...

[Sebazzz]

.oisyn schreef op dinsdag 06 juli 2010 @ 13:10:
[...]

Ah ja, dat is al een stuk genuanceerder dan wat jij zei, en waarom past Java niet in die filosofie?

Java wijkt behoorlijk af van een C-stijl taal, veel verboser bijvoorbeeld ('extends', 'implements' tegenover simpelweg ':'), en ook bijvoorbeeld álles een class is, geen structs heeft, dus enums ook een class zijn.

quote: http://en.wikipedia.org/w...9#cite_note-JohnOsborn-17

Boring repetition that lacks innovation," "Hardly anybody will claim that Java or C# are revolutionary programming languages that changed the way we write programs," and "C# borrowed a lot from Java - and vice versa. Now that C# supports boxing and unboxing, we'll have a very similar feature in Java." [17] Anders Hejlsberg has argued that C# is "not a Java clone" and is "much closer to C++" in its design.[18]

C# zit dichter bij C++ dan bij Java, dus Java is minder een C-stijl taal (dan C#).

Oh please.

Alsjeblieft.

Het ging om de mogelijkheid om die velden op te kunnen nemen. Het verschil tussen een paar en heel veel is in die discussie totaal irrelevant.

Volgens mij ging het het over 'veel velden en methodes opnemen', ik citeer mezelf. Dan zie ik overigens nog niet in wat een veld voor goeds doet. Ik vind deze constructie niet veel slechter:

C#:

enum WeekDays { Mondag, Tuesday, ..., Saturday, Sunday }

public static bool IsWeekend(this WeekDays weekDay) {
     return (weekday == ...) || (weekday == ...);
}

Wel grappig dat bepaalde mensen uiteindelijk alleen maar een discussie kunnen voeren op het discussievoeren. Net zoals die discussie tussen twee mensen twee dagen geleden, die is weggeknipt...

[ Voor 30% gewijzigd door Sebazzz op 06-07-2010 13:55 ]

[defcon84]

Snake schreef op dinsdag 06 juli 2010 @ 13:35:
Even wat anders: Windows Phone 7 ondersteund blijkbaar geen custom certificates WTF? Al die mensen die Exchange met een self signed certificate gebruiken vallen dan uit de boot. Leuk seg...

ohw.. mjah nu vallen ze helemaal uit voor ons bedrijf :-/ ze zijn het goed aant verknoeien daar..

[Haan]

Snake schreef op dinsdag 06 juli 2010 @ 13:35:
Even wat anders: Windows Phone 7 ondersteund blijkbaar geen custom certificates WTF? Al die mensen die Exchange met een self signed certificate gebruiken vallen dan uit de boot. Leuk seg...

Zal wel wat te maken hebben met security En een serieuze exchange gebruiker zal toch altijd al een certificaat aanschaffen? Zoveel hoeft dat niet te kosten.

Alhoewel, ik bedenk me net dat het certificaat op mijn werk ook niet van een CA komt, omdat een paar duizend euro per jaar zou kosten als het op mobile devices moest kunnen werken (geen idee hoe dat precies zit, ben niet zo thuis in die materie)

[ Voor 21% gewijzigd door Haan op 06-07-2010 15:21 ]

[Jan_V]

Weer een goede reden om over te stappen naar Hosted Exchange in de cloud.
Anders gaat niemand daar gebruik van maken, als je alles wel 'goedkoop' zelf kunt doen.