De Devschuur Coffee Corner

[YopY]

Meer van dat: Computer Contradictionary

Ad ROMinem adj. Relating to a personal attack on your BIOS

algorism n. A pre-LISP ALGORITHM devised by abu-Ja'far Mohammed ibn-Musa al-Khuwarzimi who wrote the first BASIC substring modifier in a vain attempt to shorten his name.

algorithm n. [Origin: ALGORISM with a pronounced LISP]

etc.

[CoolGamer]

D-Raven schreef op maandag 28 juni 2010 @ 11:32:
Bleh, wat doet vs2010 er toch lang over om te installeren. Zat nog op de RC dus ik dacht ik installeer even de RTM.... valt dat even tegen

Wees blij dat er nog geen Service Pack overheen hoeft. De installatie van die dingen duurt lang .

[Snake]

Ik hoop dat iit 2008 de SP van 2010 WEL geslipstreamed kan worden, juist gelijk bij 2005. Ik heb nooit de echte reden erachter gevonden... En die van 2008 duurde echt LANG :x

---

het is gewoonweg te warm in het bedrijf. Draai die airco aan of fuck off eh...

[Rutix]

inderaad. Belachelijk lang ook gewoon . Zowiezo vind ik de installie van VS altijd raar

[H!GHGuY]

Refro schreef op vrijdag 25 juni 2010 @ 07:38:
[...]


VALGRIND is leuk maar als je dan ook nog eens PC-Lint erop los laat vindt je echt een berg aan fouten dat pakket heeft ons hier in de organisatie echt heel erg veel geld bespaard.

Er zijn vast betere static analyzers maar lint is gewoon heel veel bang voor de buck.

Goeie code poepen kan ook helpen. Gewoon genoeg pre-condities (en dus ook pointer-validity) controleren en loggen. De software kan dan helemaal in de soep lopen, crashen zal ze wel niet doen.

[Sebazzz]

Rutix schreef op maandag 28 juni 2010 @ 20:25:
inderaad. Belachelijk lang ook gewoon . Zowiezo vind ik de installie van VS altijd raar

Het is een complex softwarepakket met veel verschillende componenten. Zo gek vind ik het niet.

[CodeCaster]

Vanmiddag wees een collega naar een technisch ontwerp van mij, en vroeg hoe ik de logger ging implementeren. Ik heb van tevoren de Sourcesafe(sorry)-repository erop nageslagen, en per project wordt er weer wat nieuws in elkaar gedraaid om te loggen. In overleg met diverse anderen heb ik dus besloten log4net te gaan gebruiken. DLL toevoegen aan het project, licentiebestandjes erbij, tabel aanmaken in de database, sample-configuratie wat aanpassen, projectdocumentatie bijwerken en in een uur was ik up&running.

"Maar je kunt toch ook zelf wat schrijven?" ... die discussie was gelukkig snel over, maar kom op.

[ Voor 6% gewijzigd door CodeCaster op 28-06-2010 21:50 ]

[jip_86]

Ja inderdaad als je iets kan vinden wat je in een uur up&running hebt ga je niet het wiel opnieuw uitvinden.

[HMS]

Tja, zelf wat schrijven heeft waarschijnlijk ook niet de flexibiliteit van log4net + je hoeft de logger code niet te onderhouden .

Zelf maar basic log4net gedaan, dus niet heel veel insight in. Maar klinkt voor grote apps wel relaxt.

[prototype]

Urgh, eigen bedrijf hebben isn't as easy as easy as it sounds, meer emailen tegenwoordig dan coden overdag, meer coden dan slapen in de nacht Volgens mij lopen hier meer startup oprichters/developers rond. Hoe gaat het bij jullie eraan toe?

[Leftblank]

prototype schreef op maandag 28 juni 2010 @ 23:48:
Urgh, eigen bedrijf hebben isn't as easy as easy as it sounds, meer emailen tegenwoordig dan coden overdag, meer coden dan slapen in de nacht Volgens mij lopen hier meer startup oprichters/developers rond. Hoe gaat het bij jullie eraan toe?

Freelancer hier, overdag mailen en 's nachts coden klinkt als een bekend ritme, hoewel m'n beeld wat vertekend zal zijn als student

[dtech]

Ugh, kom er net achter dat mijn compiler DWIS is, weet iemand een goede DWIWNWIS compiler?

[ValHallASW]

log4net, dat is toch die hopeloze configuration over convention-meuk?

C#:

            var appender = new log4net.Appender.TelnetAppender();
            appender.Port = 12369;
            
            appender.Name = "NHibernate.SQL";
            appender.Layout = new log4net.Layout.SimpleLayout();
            appender.Threshold = log4net.Core.Level.Debug;
            appender.ActivateOptions();
            lognet.Config.BasicConfigurator.Configure(appender)

Vooral die

code:

appender.ActivateOptions();

- daar heb ik echt een uur naar moeten zoeken.

I was not amused. Maargoed, je hoort geloof ik eigenlijk ook XML te gebruiken. Yuck.

[dtech]

defcon84 schreef op woensdag 23 juni 2010 @ 14:35:
[...]

AndroidMono is wel open source

http://github.com/koush/androidmono

Weet iemand welke kwaliteit dat is? Vind het er wel interresant uitzien, al is Java vergelijkbaar natuurlijk.

* dtech wil nog steeds een Java# oid maken, gewoon Java maar met een aantal zinnige dingen als properties. En dat kan dan gewoon naar Java gecompiled worden

[Sebazzz]

dtech schreef op dinsdag 29 juni 2010 @ 00:48:
[...]

* dtech wil nog steeds een Java# oid maken, gewoon Java maar met een aantal zinnige dingen als properties. En dat kan dan gewoon naar Java gecompiled worden

Er is wel een library met annotations beschikbaar die fields naar properties kan expanden maar ik weet niet of dat 'mag' of in de categorie 'slechte programmeervoorbeelden' valt. De naam van deze lib moet ik je schuldig blijven.

Wat ik overigens ook in Java mis is dat er geen preprocessor is. Kijk bijvoorbeeld naar Android en hoeveel debug en verbose messages er per seconde gelogd worden, dat wil je toch niet in je release code hebben voor een mobiel, gelimiteerd, platform?

Is er eigenlijk geen soort C#-like taal voor Java, aangezien de JVM toch taalonafhankelijk is.

[user109731]

dtech schreef op dinsdag 29 juni 2010 @ 00:48:
* dtech wil nog steeds een Java# oid maken, gewoon Java maar met een aantal zinnige dingen als properties. En dat kan dan gewoon naar Java gecompiled worden

Ken je Project Lombok? Voordeel daarvan is dat het geen aparte compiler nodig heeft, dus direct werkt met bestaande tools zoals IDE's (AFAIK, heb het niet gebruikt).

edit: great minds think alike

[ Voor 4% gewijzigd door user109731 op 29-06-2010 00:58 ]

[dtech]

Dat Project Lombok was inderdaad precies waar ik aan dacht Ik zal er eens naar gaan kijken.

Bij nader inzien is het eigenlijk ook niet zo vreemd dat waaraan ik dacht al gemaakt was, zo'n vreemde stap/gedachte is het nou ook weer niet.

edit:

Lol @ SneakyThrows

Het enige wat ik jammer vind is dat het niet een echte "compiler" is, je hebt dus altijd lombok.jar nodig in je project (maar misschien is dat ook beter). Ik vind het wel magie natuurlijk dat die .jar op een of ander manier over al jouw code heen gaat

edit2: netjes, met "delombok" kun je alle syntax vervangen door kale java

[ Voor 44% gewijzigd door dtech op 29-06-2010 07:21 ]

[Refro]

H!GHGuY schreef op maandag 28 juni 2010 @ 21:17:
[...]


Goeie code poepen kan ook helpen. Gewoon genoeg pre-condities (en dus ook pointer-validity) controleren en loggen. De software kan dan helemaal in de soep lopen, crashen zal ze wel niet doen.

Dat ben ik helemaal met je een maar hoe verifieer je dan dat je goede code hebt? Na een tijdje met lint gewerkt te hebben merk ik in ieder geval bij mezelf (en ook collegas) dat de code gewoon beter wordt minder fouten bevat en ook duidelijker te lezen is. Bovendien is het draaien van lint in onze nightly build opgenomen dus je hoeft er weinig voor te doen.

Het is ook erg fijn als je legacy code krijgt die opgeschoond moet worden met daarin functies van 5000 regels, variabele namen als DagSinterKlaasje en BusjeKomtZo, maar daar is volgens mij een ander topic voor

Gebruik je zelf wel quality tools en waarom dan wel/niet?

[Haan]

ValHallASW schreef op dinsdag 29 juni 2010 @ 00:37:
log4net, dat is toch die hopeloze configuration over convention-meuk?

C#:

            var appender = new log4net.Appender.TelnetAppender();
            appender.Port = 12369;
            
            appender.Name = "NHibernate.SQL";
            appender.Layout = new log4net.Layout.SimpleLayout();
            appender.Threshold = log4net.Core.Level.Debug;
            appender.ActivateOptions();
            lognet.Config.BasicConfigurator.Configure(appender)

Vooral die

code:

appender.ActivateOptions();

- daar heb ik echt een uur naar moeten zoeken.

I was not amused. Maargoed, je hoort geloof ik eigenlijk ook XML te gebruiken. Yuck.

Configuratie doe je inderdaad veel makkelijker in xml/ config file, lijkt me erg onhandig om configuratie te gaan hard-coden..

[YopY]

prototype schreef op maandag 28 juni 2010 @ 23:48:
Urgh, eigen bedrijf hebben isn't as easy as easy as it sounds, meer emailen tegenwoordig dan coden overdag, meer coden dan slapen in de nacht Volgens mij lopen hier meer startup oprichters/developers rond. Hoe gaat het bij jullie eraan toe?

Tijd om iemand in te huren voor de administratie en communicatie, .

Je kunt ook helemaal "2.0" gaan een een soort stackoverflow website opzetten waar algemene vragen gesteld kunnen worden en beantwoord door behulpzame vrijwilligers.

quote: Sebazz

Er is wel een library met annotations beschikbaar die fields naar properties kan expanden maar ik weet niet of dat 'mag' of in de categorie 'slechte programmeervoorbeelden' valt. De naam van deze lib moet ik je schuldig blijven.

D'r zijn tegenwoordig mensen die zeggen dat je in de praktijk eigenlijk zo weinig mogelijk getters / setters moet gebruiken. Geef de voorkeur aan ctors en / of builders, (bean) classes met alleen final properties, dat soort zaken. Voor mijn eigen projecten tot nu toe zou dat op zich wel kunnen, een ctor waar je wat velden in kunt zetten (of een builder als het veel velden zijn), en een ctor die een JDBC ResultSet kan verwerken.

Wat ik overigens ook in Java mis is dat er geen preprocessor is. Kijk bijvoorbeeld naar Android en hoeveel debug en verbose messages er per seconde gelogd worden, dat wil je toch niet in je release code hebben voor een mobiel, gelimiteerd, platform?

Goed punt, zelfs al staat die logging uit (wat met Log4J / NET kan), is die code nog steeds aanwezig en wordt het nog steeds uitgevoerd - veel opbouwen van strings e.d. Een preprocessor is één optie, echter het lijkt mij dat een JVM flag die logging calls helemaal uitschakelt of inschakelt (afhankelijk van hun niveau) meer 'Java' zou zijn - dat kun je ook met asserts doen. Die code is dan nog wel aanwezig, maar wordt (als ik het goed heb) simpelweg niet uitgevoerd.

Aspectgeoriënteerd programmeren is hier ook een mogelijke uitkomst - als je bepaalde zaken wilt gaan loggen, activeer je het logging aspect met een bepaald niveau. Ik weet niet of dat kan in Android, of dat het uberhaupt zo werkt, maar de theorie daarachter lijkt me wel logisch.

[ValHallASW]

Haan schreef op dinsdag 29 juni 2010 @ 09:00:
Configuratie doe je inderdaad veel makkelijker in xml/ config file, lijkt me erg onhandig om configuratie te gaan hard-coden..

Hangt nogal van je doel af. Als je doel is om 'even debug messages op je scherm te kunnen krijgen' dan is dit een veel logischere optie. Als je doel is om logging te kunnen doen bij software die deployed is - dan is een XML-config natuurlijk prettiger.

[Verwijderd]

Kweenie of deze oud is, maar toch: http://www.dumpert.nl/med..._java_4_ever_trailer.html

[matthijsln]

YopY schreef op dinsdag 29 juni 2010 @ 09:18:
Goed punt, zelfs al staat die logging uit (wat met Log4J / NET kan), is die code nog steeds aanwezig en wordt het nog steeds uitgevoerd - veel opbouwen van strings e.d. Een preprocessor is één optie, echter het lijkt mij dat een JVM flag die logging calls helemaal uitschakelt of inschakelt (afhankelijk van hun niveau) meer 'Java' zou zijn - dat kun je ook met asserts doen. Die code is dan nog wel aanwezig, maar wordt (als ik het goed heb) simpelweg niet uitgevoerd.

Daarvoor roep je dan isDebugEnabled() of isInfoEnabled() etc. aan als je veel gaat formatten of concatten.

[Johan.B]

Verwijderd schreef op dinsdag 29 juni 2010 @ 10:49:
Kweenie of deze oud is, maar toch: http://www.dumpert.nl/med..._java_4_ever_trailer.html

Ik had hem nog niet gezien. Zalig gewoon!
Het komende uur programmeer ik verder met een grote smile op mijn gezicht
(In Java natuurlijk

[Janoz]

ValHallASW schreef op dinsdag 29 juni 2010 @ 09:39:
Als je doel is om 'even debug messages op je scherm te kunnen krijgen' dan is dit een veel logischere optie.

Nee, dat is het niet.

[.oisyn]

Ja, dat is het wel. Al hangt het natuurlijk wel van de context af. Runtime-configurable opties kosten hoe dan ook performance, hardcoded opties die uitgeschakeld zijn niet.

[Janoz]

Dat is meer een verschil tussen compiletime en runtime, dus of je #ifdef achtige constructies kunt gebruiken. Waar ValHallASW mee bezig is is puur de configuratie van de logger. Of je dat nu in code uitschrijft of middels een configuratie bestand doet heeft op de performance geen significante impact. Het verandert immers helemaal niks aan de daadwerkelijke log statements die door de rest van de code zijn verspreid.

[.oisyn]

Ah ja dan maakt het idd niet zoveel uit.

[Rutix]

Sebazzz schreef op maandag 28 juni 2010 @ 21:35:
[...]

Het is een complex softwarepakket met veel verschillende componenten. Zo gek vind ik het niet.

Heb je weleens VS proberen te installeren met verschillende partities ? Dan wil dat ding op random partities ook dingen gaan installeren terwijl je dat niet wilt en je kunt het al helemaal niet uitzetten .

[eamelink]

Verwijderd schreef op dinsdag 29 juni 2010 @ 10:49:
Kweenie of deze oud is, maar toch: http://www.dumpert.nl/med..._java_4_ever_trailer.html

[Sebazzz]

Goed punt, zelfs al staat die logging uit (wat met Log4J / NET kan), is die code nog steeds aanwezig en wordt het nog steeds uitgevoerd - veel opbouwen van strings e.d. Een preprocessor is één optie, echter het lijkt mij dat een JVM flag die logging calls helemaal uitschakelt of inschakelt (afhankelijk van hun niveau) meer 'Java' zou zijn - dat kun je ook met asserts doen. Die code is dan nog wel aanwezig, maar wordt (als ik het goed heb) simpelweg niet uitgevoerd.

Maar je krijgt wel een probleem met VM's zonder JIT zoals vóór Android 2.2. En ik geloof dat als je logging calls in een lege methode wrapt, ze niet @ compile time eruit worden geoptimaliseerd.

Daarvoor roep je dan isDebugEnabled() of isInfoEnabled() etc. aan als je veel gaat formatten of concatten.

Debug en verbose code komt heel veel voor. Het is microoptimalisatie maar op een mobiel platform zonder JIT moet je niet anders vind ik. Een getter of setter is al relatief duur.

[Haan]

Verwijderd schreef op dinsdag 29 juni 2010 @ 10:49:
Kweenie of deze oud is, maar toch: http://www.dumpert.nl/med..._java_4_ever_trailer.html

Alleen wel vreemd dat Java wordt neergezet als de opvolger van .Net, terwijl Java er al veel eerder was.. of ga ik er nu te serieus op in

[dtech]

Haan schreef op dinsdag 29 juni 2010 @ 13:50:
[...]

Alleen wel vreemd dat Java wordt neergezet als de opvolger van .Net, terwijl Java er al veel eerder was.. of ga ik er nu te serieus op in

ja, en om met je mee te gaan: het gaat erover dat dat jongetje Java ontdekt in een Windows-biased familie. Dat jongetje ontdekt dus op een gegeve moment Java.

Dacht eerst dat het een spoof was (door ondertiteling, zoals al die Hitler-Der Untergang dingen) van een film over een jongen die erachter kwam dat ie homo was ofzo, maar het is echt originional content

[ValHallASW]

Janoz schreef op dinsdag 29 juni 2010 @ 11:14:
Nee, dat is het niet.

Interessant statement, zo zonder onderbouwing.

In dit geval wilde ik de SQL-queries die NHibernate genereerde kunnen zien. Ik vind het geen vreemde eis om dat met één regel code op m'n scherm te kunnen krijgen. In plaats daarvan heb ik dus een regel of 10 code nodig, of evenzoveel XML, waarbij ik bovendien eerst moet gaan leren hoe die XML precies werkt. Alleen: ik ben helemaal niet geïnteresseerd in hoe log4net precies werkt, ik wil weten wat NHibernate doet. Alle extra hordes die ik dan over moet springen zijn daarom al per definitie irritant.

Overigens ging mijn punt helemaal niet over XML vs hardcoded C#, maar over het feit dat ik 7 regels code nodig heb om iets simpels als logging aan te krijgen.

[ Voor 10% gewijzigd door ValHallASW op 29-06-2010 21:30 ]

[Sebazzz]

Dat doe je gecentraliseerd neem ik aan? Een singleton desnoods hoewel dat niet de beste oplossing altijd is,

[Haan]

ValHallASW schreef op dinsdag 29 juni 2010 @ 21:29:
[...]

Interessant statement, zo zonder onderbouwing.

In dit geval wilde ik de SQL-queries die NHibernate genereerde kunnen zien. Ik vind het geen vreemde eis om dat met één regel code op m'n scherm te kunnen krijgen. In plaats daarvan heb ik dus een regel of 10 code nodig, of evenzoveel XML, waarbij ik bovendien eerst moet gaan leren hoe die XML precies werkt. Alleen: ik ben helemaal niet geïnteresseerd in hoe log4net precies werkt, ik wil weten wat NHibernate doet. Alle extra hordes die ik dan over moet springen zijn daarom al per definitie irritant.

Overigens ging mijn punt helemaal niet over XML vs hardcoded C#, maar over het feit dat ik 7 regels code nodig heb om iets simpels als logging aan te krijgen.

Wat een onzin verhaal zeg. Goede logging is onmogelijk te realiseren met 1 regel code. Zelfs Debug of Trace moet je configureren voor het bruikbaar is. Geef mij dan maar een framework waar ik met alleen een paar regels xml volledige controle heb over wat er wel en niet gelogd wordt en in welk formaat. En dat hoeft niet persé log4net te zijn natuurlijk, al vind ik het zelf wel erg prettig werken

En ja, het kost je even om te leren werken met een logging framework, maar dat geldt voor zo ontzettend veel dingen, of je moet nooit iets nieuws willen leren / uitproberen. Als ik voor mezelf spreek, heb ik misschien een halve tot een hele dag besteed aan het ontdekken van log4net in de afgelopen paar maanden, maar die tijd heb ik ook al weer terug gewonnen doordat je aan de ene kant nauwelijks tijd meer kwijt bent aan het implementeren van logging (en als je eenmaal de configuratie gedaan hebt, is het een kwestie van copy/paste in een nieuw project), en aan de andere kant ben je minder tijd kwijt aan het oplossen van problemen. Het is super makkelijk om in een productieomgeving even het log level op INFO of DEBUG te kunnen zetten, zodat er allemaal log-informatie uitgespuugd wordt.

[ValHallASW]

Haan schreef op dinsdag 29 juni 2010 @ 21:47:
Wat een onzin verhaal zeg. Goede logging is onmogelijk te realiseren met 1 regel code.

Python:

logging.basicConfig(level=logging.DEBUG)

Nee? Dit doet in de context die ik beschreven heb precies wat ik wil, maar dat is dus onmogelijk met log4net. Dat de hele C#-wereld met configuration-over-convention werkt in plaats van andersom doet daar niets aan af.

En ja, het kost je even om te leren werken met een logging framework, maar dat geldt voor zo ontzettend veel dingen, of je moet nooit iets nieuws willen leren / uitproberen. Als ik voor mezelf spreek, heb ik misschien een halve tot een hele dag besteed aan het ontdekken van log4net in de afgelopen paar maanden, maar die tijd heb ik ook al weer terug gewonnen doordat je aan de ene kant nauwelijks tijd meer kwijt bent aan het implementeren van logging (en als je eenmaal de configuratie gedaan hebt, is het een kwestie van copy/paste in een nieuw project),

Ik vind het ook prima om een halve dag te besteden aan het leren van een logging framework als het gaat om het implementeren van logging in mijn eigen applicatie. Op het moment dat ik probeer uit te zoeken wat een 3rd party library uitspookt wil ik alleen geen halve dag kwijt zijn aan het leren van het logging framework dat die library toevallig gebruikt.

Overigens neemt dat niet weg dat een configuratie die in zinnig in één regel kan ook gewoon in één regel zou moeten. Sensible defaults, convention over configuration, jeweetwel.

[Woy]

Ik ben het wel met ValHallASW dat het makkelijk was geweest als er een aantal standaard configuraties aanwezig waren geweest, waar je alleen het logging level aan mee hoeft te geven.

Bijvoorbeeld een Console/TextFile/XmlFile/EventLog configuratie, die gewoon alles regelen. Als je daar dan vanaf wil wijken kun je dat perfect via de huidige manier doen.

[Sebazzz]

Vooral verbose logs zijn handig, alleen wel dubbel ^^

edit: en dan ineens je dubbelpost verwijderen hè

[ Voor 34% gewijzigd door Sebazzz op 30-06-2010 01:02 ]

[matthijsln]

ValHallASW schreef op dinsdag 29 juni 2010 @ 22:38:
Ik vind het ook prima om een halve dag te besteden aan het leren van een logging framework als het gaat om het implementeren van logging in mijn eigen applicatie. Op het moment dat ik probeer uit te zoeken wat een 3rd party library uitspookt wil ik alleen geen halve dag kwijt zijn aan het leren van het logging framework dat die library toevallig gebruikt.

In het geval van NHibernate kan je natuurlijk ook gewoon <property name="show_sql">true</property> in je hibernate.cfg.xml zetten. Dit vereist 0,0 log4net configuratie...

[ValHallASW]

Ja. Ware het niet dat dat a) niet werkt en b) sowieso al niet werkt voor een WPF-app die geen console heeft (hoewel daar vast wel trucjes voor zijn).
en ja, ik heb ook de versie-met-namespace <add key="hibernate.show_sql" value="true"/>, die door de rest van het internet gebruikt wordt, geprobeerd

Oh, en dat het niet werkt heeft vast iets te maken met het inlezen van verkeerde configuratiefiles ofzo, maar net zo min als ik zin heb om om een logging framework te leren heb ik zin om uitgebreid te gaan debuggen waarom third party software niet doet wat in de handleiding staat.

als je hier wat frustratie proeft: ja, dat klopt

On a more positive note, er is in ieder geval logging, hoeveel moeite het ook kost daar uitvoer van te krijgen :-)

[ Voor 22% gewijzigd door ValHallASW op 30-06-2010 07:33 ]

[matthijsln]

Hmm ja dat is dan lastig. Ik was even vergeten dat je in Windows niet altijd een console hebt. Ik heb ooit wel eens OutputDebugString() gebruikt in een win32 app, die kreeg je dan wel in Visual Studio te zien. Maar daar heb je nu niks aan

[YopY]

matthijsln schreef op dinsdag 29 juni 2010 @ 10:59:
Daarvoor roep je dan isDebugEnabled() of isInfoEnabled() etc. aan als je veel gaat formatten of concatten.

Dat spreekt voor zich. Echter, waar leg je dan de grens? Een stuk code vol met:

Java:

if (log.isDebugEnabled()) {
    log.debug("Output: " + obj.toString());
}

gaat op den duur storen, . * YopY moet zich toch maar eens AOP aanleren.

[Alex)]

Ja, dat refactor je dan natuurlijk naar:

C#:

DebuggingHelper.Debug("Output: " + obj.ToString());

Waarbij de DebugHelper een klasse is en Debug een static method die die check weer doet.

[Matis]

Dan hoef je in feite ook alleen het object te passen

[defcon84]

ValHallASW schreef op dinsdag 29 juni 2010 @ 22:38:
[...]

Python:

logging.basicConfig(level=logging.DEBUG)

Nee? Dit doet in de context die ik beschreven heb precies wat ik wil, maar dat is dus onmogelijk met log4net. Dat de hele C#-wereld met configuration-over-convention werkt in plaats van andersom doet daar niets aan af.

je zal waarschijnlijk wel "import logging" of iets moeten toevoegen aan je page.. en in die class staat dan weer meer dan 1 regel code hoor dus nee, loggen kan je niet met 1 regel in totaal.. wel 1 regel om de log method aan te roepen natuurlijk. en dat is de bedoeling.

C#:

namespace DefconsApp
{
    public class Log
    {
        public enum Level
        {
            CRITICAL = 1,
            SEVERE = 2,
            WARNING = 3,
            NOTICE = 4,
            DEBUG = 5
        }

        /// <summary>
        /// Creats a new log entry
        /// </summary>
        /// <param name="message">the log message</param>
        /// <param name="level">The severety of the log message</param>
        /// <remarks></remarks>
        public static void New(string message, Level level)
        {
            using (SqlConnection con = DbManager.GetDbConnection) {
                using (SqlCommand com = con.CreateCommand) {
                    // SQL crap here..
                }
            }
        }
    }
}

en dan kan je het (natuurlijk) aanroepen met 1 regel

C#:

Log.Create("ooeehh hier ging iets goed mis..", Log.Level.WARNING)

[RayNbow]

defcon84 schreef op woensdag 30 juni 2010 @ 09:30:
[...]

je zal waarschijnlijk wel "import logging" of iets moeten toevoegen aan je page..

Dat past ook wel nog op 1 regel hoor...

Python:

_ = (lambda x: (globals().setdefault('logging',x), logging.basicConfig(level=logging.DEBUG)))(__import__("logging"))

[defcon84]

RayNbow schreef op woensdag 30 juni 2010 @ 09:36:
[...]

Dat past ook wel nog op 1 regel hoor...

Python:

_ = (lambda x: (globals().setdefault('logging',x), logging.basicConfig(level=logging.DEBUG)))(__import__("logging"))

Lambda ja
maar ik had het niet over Python
maar in .NET kan je het wss ook klaar krijgen met L2S

[RayNbow]

defcon84 schreef op woensdag 30 juni 2010 @ 09:55:
[...]

Lambda ja
maar ik had het niet over Python

Het stukje code in je quote was echter wel in Python.

maar in .NET kan je het wss ook klaar krijgen met L2S

Hoe wil je dat doen in bijv. een statische taal als C#? In Python kan ik namelijk via globals() de globale namespace veranderen. In C# kan dit niet en kan ik dus niet dynamisch variabelen "aanmaken".

[Haan]

RayNbow schreef op woensdag 30 juni 2010 @ 10:17:

Hoe wil je dat doen in bijv. een statische taal als C#? In Python kan ik namelijk via globals() de globale namespace veranderen. In C# kan dit niet en kan ik dus niet dynamisch variabelen "aanmaken".

In C# 4.0 is het dynamic keyword geïntroduceerd, waarmee dat wel kan (als ik goed denk te begrijpen wat je bedoelt), zie bijvoorbeeld Using the Dynamic Keyword in C# 4.0

[ Voor 4% gewijzigd door Haan op 30-06-2010 10:29 ]

[.oisyn]

Nee, daarmee kun je niet variabelen at runtime definieren. Dynamic variabelen zijn nog steeds at compiletime al gedefinieerd, alleen het type nog niet.

[Alex)]

Als je at runtime variabelen wil definiëren zul je wel met Reflection aan de gang moeten denk ik zo. Maar degene die ik dat zie doen zonder dat hij er een hele goede reden voor heeft, krijgt van mij een klap voor z'n harses.

C#:

var ldc = new LoggingDataContext(); ldc.Logs.InsertOnSubmit(new Log { Severity = 4, Message = "Aap failed to eat banana" }); ldc.SubmitChanges();

[RayNbow]

Edit: spuit11, zie .oisyn in "De Devschuur Coffee Corner"

Haan schreef op woensdag 30 juni 2010 @ 10:29:
[...]

In C# 4.0 is het dynamic keyword geïntroduceerd, waarmee dat wel kan (als ik goed denk te begrijpen wat je bedoelt), zie bijvoorbeeld Using the Dynamic Keyword in C# 4.0

Met dynamic kan je alsnog niet op een dynamische wijze variabelen aanmaken. Dynamic is niets anders dan een bepaald type in het typesysteem. De variabele die je declareert met "dynamic <ident> = <initvalue>;" wordt nog steeds op een statische manier gedeclareerd.

Wat je niet in C# kunt doen, maar wel in Python (en ook in o.a. JavaScript) is het volgende:

Python:

for i in range(2):
    globals()['x'+str(i)] = i

print x0, x1

[ Voor 5% gewijzigd door RayNbow op 30-06-2010 10:38 ]

[Haan]

IC. Maar even voor mijn begrip, heeft iemand een praktijksituatie / voorbeeld waarin je dat zou kunnen gebruiken?

edit:
was een reactie op oisyn..

[ Voor 15% gewijzigd door Haan op 30-06-2010 10:40 ]

[Exirion]

Google heeft een Power Meter API die bedoeld is voor embedded platformpjes om gemeten verbruik periodiek te uploaden. Als je een query doet krijg je een shitload XML binnen waarbij _elke_ sample in een veel te grote berg tekst verborgen, wat wil zeggen: een hele ruime 1 KB. Daar zit je dan met je Cortex-M3 met 32KB RAM of maximaal 6KB. De boel werkt ook nog eens met HTTPS zodat je het e.e.a. nodig heb om uberhaupt te kunnen communiceren met de service. Ze hadden er misschien iets beter over na kunnen denken

[.oisyn]

@Haan: Bindings met scripttalen en databases, duck typing waarbij verschillende typen objecten dezelfde methods implementeren (maar niet dezelfde interface), multi-dispatch... Ik heb er zelf nog niet mee gewerkt, maar dat is waar ik zo even aan kan denken. Vooral multi-dispatch lijkt me ideaal

[ Voor 3% gewijzigd door .oisyn op 30-06-2010 11:07 ]

[YopY]

Alex) schreef op woensdag 30 juni 2010 @ 09:26:
Ja, dat refactor je dan natuurlijk naar:

C#:

DebuggingHelper.Debug("Output: " + obj.ToString());

Waarbij de DebugHelper een klasse is en Debug een static method die die check weer doet.

Maar dan ben je weer terug bij A, want dan wordt altijd de concat + de toString() uitgevoerd, onafhankelijk van je logging niveau. Daar gaat het me even om, en daarom moet je óf die call doen naar isDebugEnabled(), óf AOP toepassen die de logging fysiek uit de bytecode sloopt, óf moet logging aan- of uitzetten dmv een Java param kunnen.

[Alex)]

Ahja, juist.

C#:

#if DEBUG
Logger.Log("Output: " + obj.ToString());
#endif

Zoiets bedoel je dan?

[Haan]

Alex) schreef op woensdag 30 juni 2010 @ 11:13:
Ahja, juist.

C#:

#if DEBUG
Logger.Log("Output: " + obj.ToString());
#endif

Zoiets bedoel je dan?

En dan ben je precies weer terug bij het punt van YopY, dat je hele code vol ruis rondom de logging staat.

[dtech]

RayNbow schreef op woensdag 30 juni 2010 @ 10:38:

Wat je niet in C# kunt doen, maar wel in Python (en ook in o.a. JavaScript) is het volgende:

Python:

for i in range(2):
    globals()['x'+str(i)] = i

print x0, x1

De vraag is waarom je in hemelsnaam met dat soort variabele variabelen wil werken. In 99,99999% van de gevallen heb je gewoon een array nodig. In 100% van de gevallen kan het ook anders opgelost worden.

[Haan]

dtech schreef op woensdag 30 juni 2010 @ 11:40:
[...]


De vraag is waarom je in hemelsnaam met dat soort variabele variabelen wil werken. In 99,99999% van de gevallen heb je gewoon een array nodig. In 100% van de gevallen kan het ook anders opgelost worden.

Inderdaad, als je dat soort code ziet, is het een zege dat zoiets niet kan in C#

[defcon84]

dtech schreef op woensdag 30 juni 2010 @ 11:40:
[...]


De vraag is waarom je in hemelsnaam met dat soort variabele variabelen wil werken. In 99,99999% van de gevallen heb je gewoon een array nodig. In 100% van de gevallen kan het ook anders opgelost worden.

ik zie het nut er ook niet van in..
en x[1], x[2] werkt net zo goed

[YopY]

Alex) schreef op woensdag 30 juni 2010 @ 11:13:

C#:

#if DEBUG
Logger.Log("Output: " + obj.ToString());
#endif

Zoiets bedoel je dan?

Haan schreef op woensdag 30 juni 2010 @ 11:17:
En dan ben je precies weer terug bij het punt van YopY, dat je hele code vol ruis rondom de logging staat.

En is het rondje nog meer terug bij A, waarbij het gebrek aan een preprocessor bij Java aangemerkt werdt (door Sebaz³), .

Denk dat AOP toch het dichste bij komt. Alleen dan zul je (denk ik?) nog wel iets neer moeten zetten (een soort van hook) waarmee je aangeeft "Hier moet je iets neer kunnen zetten @ runtime". Ik heb me er niet echt in verdiept, maar out of the box kun je code 'injecteren' voor en na de aanroep van een functie, en kun je tussendoor dingen 'injecteren' dmv een pointcut. Maar ik weet het niet. Komt op de todo lijst, .

[RayNbow]

dtech schreef op woensdag 30 juni 2010 @ 11:40:
[...]


De vraag is waarom je in hemelsnaam met dat soort variabele variabelen wil werken. In 99,99999% van de gevallen heb je gewoon een array nodig. In 100% van de gevallen kan het ook anders opgelost worden.

Dit was louter een voorbeeld om te illustreren wat ik gebruikte in de import-oneliner een paar posts terug.

[Janoz]

ValHallASW schreef op dinsdag 29 juni 2010 @ 21:29:
[...]

Interessant statement, zo zonder onderbouwing.

Net zo veel onderbouwing als het statement waarop ik reageerde . Het ging echter inderdaad over het verschil tussen deconfiguratie hardcoded in je code (bad!) en configuratie buiten je code. Wel grappig trouwens dat de rest van je post daar dan ook verder helemaal niet op ingaat.

Ik weet niet hoe log4net werkt. Ik heb alleen ervaring met Log4J. Waneer ik Hibernate logging aan wil zetten (of op een hoger niveau) heb ik enkel de volgende 3 regels nodig in mijn log4j.xml:

XML:

    <category name="org.hibernate.SQL">
        <priority value="TRACE"/>
    </category>

En dat is alleen wanneer je uberhaupt nog niks er over in had staan. Wanneer het er al staat is het simpel een kwestie van INFO of ERROR vervangen door TRACE (of andersom om het weer uit te zetten)

Ja, er zit meer code in het log4j bestand, maar imho is dat bestandje onderdeel van je project setup (waarbij je eventueel zelfs verschillende log4j.xml bestanden hebt voor elke stap in je otap straat)

Woy schreef op dinsdag 29 juni 2010 @ 22:45:
Ik ben het wel met ValHallASW dat het makkelijk was geweest als er een aantal standaard configuraties aanwezig waren geweest, waar je alleen het logging level aan mee hoeft te geven.

Bijvoorbeeld een Console/TextFile/XmlFile/EventLog configuratie, die gewoon alles regelen. Als je daar dan vanaf wil wijken kun je dat perfect via de huidige manier doen.

Gewoon een standaard logbestandje onderdeel maken van je project template en klaar is kees.

Maar goed. Disclaimer: Ik baseer alles op log4j.

[defcon84]

gebruik in C# ofwel [Conditional("DEBUG")] ofwel iets als Logger.Log(() => "Output: " + obj.ToString())
in laatste geval gaat't om een delegate die dan pas uitgevoerd dient te worden als loglevel juist staat

[Sebazzz]

Wel grappig dat die method calls @ compile time niet zomaar worden weggeoptimaliseerd.

C#:

static void Main(string[] args) {
    Random r = new Random();

    int i = r.Next();
    LogTextStr(            "Str:    I can haz number "+i);

    i = r.Next();
    LogTextStrEmpty(       "Str(e): I can haz number"+i);

    i = r.Next();
    int i1 = i;
    LogTextFunc(() =>      "Func:   I can haz number"+i1);

    i = r.Next();
    int i2 = i;
    LogTextFuncEmpty(() => "Func(e):I can haz number"+i2);

    i = r.Next();
    int i3 = i;
    LogTextExpr(() =>      "Expr:   I can haz number"+i3);

    i = r.Next();
    int i4 = i;
    LogTextExprEmpty(() => "Expr:   I can haz number"+i4);

    System.Diagnostics.Debug.Assert(i != int.MaxValue);

    System.Diagnostics.Debug.WriteLine("waah"+i);
}

Geeft:

C#:

private static void Main(string[] args)
{
    <>c__DisplayClass2 CS$<>8__locals3;
    Random r = new Random();
    LogTextStr("Str:    I can haz number " + r.Next());
    LogTextStrEmpty("Str(e): I can haz number" + r.Next());
    int i = r.Next();
    int i1 = i;
    LogTextFunc(new Func<string>(CS$<>8__locals3, (IntPtr) this.<Main>b__0));
    i = r.Next();
    int i2 = i;
    LogTextFuncEmpty(new Func<string>(CS$<>8__locals3, (IntPtr) this.<Main>b__1));
    i = r.Next();
    int i3 = i;
    LogTextExpr(Expression.Lambda<Func<string>>(Expression.Add(Expression.Constant("Expr:   I can haz number", typeof(string)), Expression.Convert(Expression.Constant(i3), typeof(object)), (MethodInfo) methodof(string.Concat)), new ParameterExpression[0]));
    i = r.Next();
    int i4 = i;
    LogTextExprEmpty(Expression.Lambda<Func<string>>(Expression.Add(Expression.Constant("Expr:   I can haz number", typeof(string)), Expression.Convert(Expression.Constant(i4), typeof(object)), (MethodInfo) methodof(string.Concat)), new ParameterExpression[0]));
}

Debug wordt uiteraard wel weggeoptimaliseerd maar de calls naar lege methodes (****Empty(...)) niet. Dit had ik niet verwacht want het uitvoeren van de lege methode heeft in dit geval geen invloed op de verdere executie van het programma.

Ik weet het niet zeker, maar ik kan me voorstellen dat het door de JIT wel wordt weggeoptimaliseerd.

[.oisyn]

Dat de compiler het niet weghaalt wil niet zeggen dat de JITer het ook niet weghaalt [.edit: euh ja dat zei je al, even over je laatste zin heen gelezen]. Overigens, als de JITer het weghaalt dan is de lambda constructie ook niet meer nodig, tenzij je expressie nog andere side-effects heeft.

[ Voor 14% gewijzigd door .oisyn op 30-06-2010 17:13 ]

[Sebazzz]

Als je expressie side-effects hebt ben je niet goed bezig. In een assertation hoor je ook geen dingen uit te voeren, alleen te vergelijken. Anders kan je bugs krijgen in een release build die je in de debug build niet hebt.

[.oisyn]

Ik benaderde het van de point of view van de compiler. Natuurlijk moet een dergelijke expressie geen side-effect hebben, en als je dat wel doet ben je idd dom bezig . Overigens zal de laatste bug waarin er wordt geassert op het resultaat van een functie nog niet geschreven zijn

Zo hadden we ooit eens een game die in de final build geen belichting had. Bleek er een ASSERT(DoLighting()) in de code te staan

[ Voor 5% gewijzigd door .oisyn op 30-06-2010 17:21 ]

[user109731]

Sebazzz schreef op woensdag 30 juni 2010 @ 15:06:
Debug wordt uiteraard wel weggeoptimaliseerd maar de calls naar lege methodes (****Empty(...)) niet. Dit had ik niet verwacht want het uitvoeren van de lege methode heeft in dit geval geen invloed op de verdere executie van het programma.

Ik stel me voor dat de C# compiler redelijk rechttoe-rechtaan bytecode emit. De JIT optimaliseert dit pas, o.a. om te voorkomen dat elke frontend dit soort optimalisaties zelf moet doen. En dan is dit gedrag heel logisch, Debug.WriteLine kan nl. niet door de JIT geoptimaliseerd worden (alle Debug.* code moet eruit, ondanks mogelijke side-effects) en moet daarom door de compiler eruit gehaald worden (aangenomen dat de JIT niet het verschil tussen Debug/Release weet). Voor alle andere code is het beter om dit op bytecode-niveau te doen.

Imho is het ook mooier als de bytecode de originele code zo goed mogelijk representeert, er zijn tools (AspectJ voor Java bijvoorbeeld) die direct werken met bytecode en dan kan het een voordeel zijn. Ook voor debugging is het beter, veel JIT-compilers vallen terug op een bytecode interpreter of genereren minder geoptimaliseerde code als een debugger gebruikt wordt. Zou de C#-compiler wel optimaliseren dan kan dit niet omdat locals, functie calls etc. al weggeoptimaliseerd zijn. Dit merk je bij C++ release builds: daar debug je wel direct geoptimaliseerde code, zodat bijv. bepaalde variabelen niet weergegeven worden

[ Voor 16% gewijzigd door user109731 op 01-07-2010 01:30 ]

[Sebazzz]

Blijkbaar zijn die JITers tegenwoordig zo snel dat het niet uitmaakt of het door de JITer of compiler wordt gedaan? Ik kan me wel voorstellen dat het door programma's als NGen wordt weggeoptimaliseerd, omdat die er een native binary van maken.

[Cartman!]

Upgrade ik NetBeans naar versie 6.9 en vervolgens werkt refactoren niet meer, onvoorstelbaar Moet ik weer terug naar 6.9M1

[Laurens-R]

Het overgrote deel van het verschil zit hem idd in het JIT gedrag. Quote van Scott Hanselman:

However, most of the optimizations in managed code are done by the JIT compiler rather than the language compiler.

edit: removed BS.

Btw... kan iemand me uitleggen waarom sommige ontwikkelaars zoveel moeite hebben met de C++ STL? Het idee achter de library is toch prima? Waarom lees ik dan toch zoveel negatieve geluiden op blogs e.d.?

[ Voor 96% gewijzigd door Laurens-R op 01-07-2010 20:00 ]

[Sebazzz]

Zo, ik ga maar weer eens aan een C++ app beginnen. Gewoon simpel beginnen, een programma dat Fibonacci uitrekent. Ik werk wel regelmatig met .NET en C# maar om één of andere reden blijf ik toch een soort oude liefde voor C++ houden. Oke, ik ben er nooit erg ver mee geweest (alleen een Firefox backup applicatie mee geschreven) maar toch vind ik het om één of andere reden leuk om zo raw te werken

[mux]

dtech schreef op woensdag 30 juni 2010 @ 11:40:
[...]


De vraag is waarom je in hemelsnaam met dat soort variabele variabelen wil werken. In 99,99999% van de gevallen heb je gewoon een array nodig. In 100% van de gevallen kan het ook anders opgelost worden.

Het is anders best handig voor de leesbaarheid hoor:

code:

var elementenDieIkWilAanspreken = new Array('meuk', 'zooi', 'foo', 'bar');

(...)

for (klotezooi in elementenDieIkWilAanspreken){
  moederElement[klotezooi].doeIets();
  moederElement['sub' + klotezooi].doeIetsAnders();
  moederElement['subsub' + klotezooi].doeNogIetsAnders();
}

(...)

Je zit in JS aan IDs vast waar (meestal, bij names dan weer wel) geen arrays van kunnen worden gemaakt, dus als je subelementen wilt aanspreken komen er constructies als id='moeder_kind_subkind' etc. Dat valt natuurlijk weer netter op te lossen door gewoon de childnodes van de DOM in te duiken, maar om eerlijk te zijn vind ik dit een heel stuk netter en leesbaarder - je laat in je code direct en niet-cryptisch zien waar je mee bezig bent, zodat zelfs ik zie wat er gebeurt.

[roy-t]

Ah ja, ik begin de charme er ook wel van te zien, pointers zijn gaaf. Maar toch had ik het idee dat C je nog net dat beetje extras gaf. (C++ is daarintegen een stuk praktischer)

[.oisyn]

Wat voor extra's geeft C dan? Ik bedoel, C code kun je doorgaans ook gewoon door C++ compiler halen (op wat implicit pointer casts na)

[dtech]

C++ is inderdaad voor het grootste deel een uitbreiding van C (geen superset, zoals bijv. objective-C dat wel is), maar een strikte C++ compiler zal wel wat dingetjes tegenkomen (te beginnen al bij de standaard headers <stdio.h> vs <cstdio> e.d.).

Ik ken echter eigenlijk geen enkele C++ compiler die niet ook zonder problemen C kan compiler.

wikipedia over de verschillen

[.oisyn]

Waar het om ging is het schrijven van code. C biedt niets extra's tov C++ als je erin gaat programmeren. Nou ja, behalve variadic macro's, maar die ondersteunen de meeste C++ compilers ook wel .

Overigens mis ik in dat lijstje daar nog het feit dat een functie-declaratie zonder parameters in C betekent dat de parameters ongespecificeerd zijn, en niet zoals in C++ dat de functie dan gewoon geen parameters verwacht (daarvoor moet je in C void gebruiken als 'parameter').

.edit: zo, maar meteen even toegevoegd

[ Voor 4% gewijzigd door .oisyn op 02-07-2010 12:32 ]

[farlane]

.oisyn schreef op vrijdag 02 juli 2010 @ 12:18:
C biedt niets extra's tov C++ als je erin gaat programmeren.

Nog eentje:

Variable-length arrays are not among them.

[roy-t]

In C is het voor mij door het ontbreken van het 'new' keyword gewoon net wat beter te zien wat er gebeurd. Ook het hele gebeuren met structs, waar je in C++ natuurlijk vaak objecten voor gebruikt vond ik interessant. Tuurlijk gebruik ik nu C++. Maar C was echt een beetje een eyeopener voor mij (eerst unmanaged taal waar ik in werk trouwens).

Trouwens: het lijkt me een erg interessant hobby project om een C library te schrijven waardoor je OO kan doen in C. Tuurlijk bestaat dit al als C++ en in de Linux Kernel, maar het lijkt me een heel goede manier om echt goed OO te leren.

[ Voor 42% gewijzigd door roy-t op 02-07-2010 13:44 ]

[mux]

IMO is C uitstekend voor embedded spul te gebruiken, maar onnodig voor high-level OS-draaiend spul. In C zit je dicht op de hardware, C++ maakt het programmeren wat makkelijker voor je.

C kun je bij wijze van spreken direct in assembly omzetten, waar dat bij C++ soms nog wel wat denkstappen nodig heeft.

[RayNbow]

.oisyn schreef op vrijdag 02 juli 2010 @ 10:42:
(op wat implicit pointer casts na)

...en op wat nieuwe reserved keywords na.

roy-t schreef op vrijdag 02 juli 2010 @ 13:43:
Trouwens: het lijkt me een erg interessant hobby project om een C library te schrijven waardoor je OO kan doen in C. Tuurlijk bestaat dit al als C++ en in de Linux Kernel, maar het lijkt me een heel goede manier om echt goed OO te leren.

Meeste compilervakken behandelen tegenwoordig toch wel hoe je een OO-taal compileert naar iets als C?

[Alex)]

Wat is Sharepoint een apart product... ik zit het nu te branden (lees: masterpages schrijven, CSS aanpassen e.d.) en dingen zijn soms totaal niet consequent opgelost. Zoals een breadcrumbnavigatie die op sommige pagina's ineens weer ergens anders staat enzo.

[.oisyn]

roy-t schreef op vrijdag 02 juli 2010 @ 13:43:
In C is het voor mij door het ontbreken van het 'new' keyword gewoon net wat beter te zien wat er gebeurd.

Maar malloc() bestaat nog steeds. Mijn hele punt was, je kunt met C++ prima C-like code schrijven. Het voordeel is dat je hier en daar toch van de C++ features zoals operator overloading gebruik kunt maken.

Trouwens: het lijkt me een erg interessant hobby project om een C library te schrijven waardoor je OO kan doen in C.

Wat voor library is daarvoor nodig dan? 't Is een kwestie van structs definieren en functies maken die op die structs opereren. Dat moet je voor elke "class" opnieuw doen, daar heb je geen library voor nodig.

[roy-t]

@.Oisyn. Achja het was maar een soort van gevoel, je moet alles niet te letterlijk nemen wat ik net zei, het was gewoon een beetje een openbaring.

RayNbow schreef op vrijdag 02 juli 2010 @ 14:27:
[...]

...en op wat nieuwe reserved keywords na.


[...]

Meeste compilervakken behandelen tegenwoordig toch wel hoe je een OO-taal compileert naar iets als C?

Als er uberhaupt nog compilervakken gegeven worden that is. Hier niet in ieder geval.

[FragFrog]

roy-t schreef op vrijdag 02 juli 2010 @ 15:36:

Als er uberhaupt nog compilervakken gegeven worden that is. Hier niet in ieder geval.

Que? Brokken's C cursus heeft voor zover ik weet nog steeds een deel compiler schrijven toch?

* FragFrog vond net een proxychecker HTTP request in z'n WebSocket server logs

Wat ietwat vreemd is aangezien die volgens mij nog nergens gelinkt is. Maf, spambots lijken beter 't web af te struinen dan google...

[ Voor 28% gewijzigd door FragFrog op 02-07-2010 15:54 ]

[Jan_V]

Alex) schreef op vrijdag 02 juli 2010 @ 14:28:
Wat is Sharepoint een apart product... ik zit het nu te branden (lees: masterpages schrijven, CSS aanpassen e.d.) en dingen zijn soms totaal niet consequent opgelost. Zoals een breadcrumbnavigatie die op sommige pagina's ineens weer ergens anders staat enzo.

Probeer het daarna maar eens compatibel te maken met andere browsers. Pff...heb er inmiddels redelijk wat dagen in zitten om alles visueel een beetje goed te krijgen. Ben natuurlijk ook geen designer, dus waarschijnlijk zal een echte html/css/js guru het veel sneller kunnen.

[user109731]

De C++ FAQ Lite moet ook even genoemd worden, verplichte kost voor iedere C++-er. Behandelt heel veel C++-features, vreemde constructies die je in het wild tegenkomt en bijvoorbeeld ook het genoemde f(void) vs. f()

[ Voor 8% gewijzigd door user109731 op 02-07-2010 19:59 ]

[Alex)]

Jan_V schreef op vrijdag 02 juli 2010 @ 19:23:
[...]

Probeer het daarna maar eens compatibel te maken met andere browsers. Pff...heb er inmiddels redelijk wat dagen in zitten om alles visueel een beetje goed te krijgen. Ben natuurlijk ook geen designer, dus waarschijnlijk zal een echte html/css/js guru het veel sneller kunnen.

Ja, klopt. Gelukkig (?) is de doelgroep voor dit ding alleen maar IE 7 / IE 8. Nou is het echt waardeloos developen met IE 7, ik heb dus al snel Firefox ernaastgezet en test daarin. Míjn werk werkt i.i.g. goed crossbrowser.

[Janoz]

roy-t schreef op vrijdag 02 juli 2010 @ 15:36:
Als er uberhaupt nog compilervakken gegeven worden that is. Hier niet in ieder geval.

Geven ze in Groningen geen vertalerbouw meer (Als ik me goed herinner vroeger door Hesselink gegeven)? Dat is wel erg jammer. Typisch zo'n vak dat je net weer even wat extra inzichten geeft.

[farlane]

JanDM schreef op vrijdag 02 juli 2010 @ 19:57:
De C++ FAQ Lite moet ook even genoemd worden, verplichte kost voor iedere C++-er. Behandelt heel veel C++-features, vreemde constructies die je in het wild tegenkomt en bijvoorbeeld ook het genoemde f(void) vs. f()

Is een informatieve site, echter het lijkt wel alsof de schrijver steeds meer "don't do this and this, do this and this ( because i say so )" begint te worden

[roy-t]

Janoz schreef op vrijdag 02 juli 2010 @ 22:19:
[...]


Geven ze in Groningen geen vertalerbouw meer (Als ik me goed herinner vroeger door Hesselink gegeven)? Dat is wel erg jammer. Typisch zo'n vak dat je net weer even wat extra inzichten geeft.

Hesselink is met pensioen .

@ FragFrog: de C++ cursus van Frank Brokken zit niet in het standaard pakket informatica. En is eigenlijk te zwaar om zomaar ernaast te volgen (tenzij je nog wat tijd over hebt natuurlijk).

[Exirion]

ssj3gohan schreef op vrijdag 02 juli 2010 @ 14:26:
IMO is C uitstekend voor embedded spul te gebruiken, maar onnodig voor high-level OS-draaiend spul. In C zit je dicht op de hardware, C++ maakt het programmeren wat makkelijker voor je.

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.

[FragFrog]

roy-t schreef op vrijdag 02 juli 2010 @ 23:58:
@ FragFrog: de C++ cursus van Frank Brokken zit niet in het standaard pakket informatica. En is eigenlijk te zwaar om zomaar ernaast te volgen (tenzij je nog wat tijd over hebt natuurlijk).

Daar heb je een minor voor Besides, zo zwaar is'ie ook niet - ik heb in elk geval het eerste deel vrij eenvoudig naast m'n normale vakken kunnen volgen indertijd

Then again, ik heb afgelopen periode ook een vijf EC robotica practicum extra gevolgd, wellicht denk ik er wat makkelijk over

[ Voor 12% gewijzigd door FragFrog op 03-07-2010 00:21 ]

[.oisyn]

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.

De denkfout die men vaak maakt is dat je in C++ OO moet programmeren, of dat je in C procedureel bezig moet zijn. Als beide compilers beschikbaar zijn, waarom zou je dan überhaupt voor de C compiler kiezen?

[ Voor 5% gewijzigd door .oisyn op 03-07-2010 00:29 ]

[Exirion]

.oisyn schreef op zaterdag 03 juli 2010 @ 00:28:
De denkfout die men vaak maakt is dat je in C++ OO moet programmeren, of dat je in C procedureel bezig moet zijn. Als beide compilers beschikbaar zijn, waarom zou je dan überhaupt voor de C compiler kiezen?

Waarom zou je voor Python kiezen als je BASIC kunt gebruiken en waarom zou je C# gebruiken terwijl je ook Java met een JIT compiler kunt gebruiken? De 1 gebruikt graag C en de ander graag C++. En wees eens eerlijk: 9 van de 10 keer dat C++ boven wordt C wordt aangeprezen gaat het over OO. Dat is precies waartegen ik ageer.

[.oisyn]

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

Waarom zou je voor Python kiezen als je BASIC kunt gebruiken en waarom zou je C# gebruiken terwijl je ook Java met een JIT compiler kunt gebruiken?

Je snapt zelf ook wel dat je in de regel gewoon C code kunt schrijven mbv een C++ compiler. Dat heb ik nu geloof ik al 4x gezegd. Python code kun je niet door een BASIC compiler halen, en ook de JVM kan geen .Net code uitvoeren.

En wees eens eerlijk: 9 van de 10 keer dat C++ boven wordt C wordt aangeprezen gaat het over OO. Dat is precies waartegen ik ageer.

En dat is ook precies waarom ik erop hamer dat de keuze voor een C++ compiler niet meteen betekent dat je ook OO moet gaan programmeren. Maar ondertussen biedt het je wel veel andere handige features, zoals templates, references, function overloading en operator overloading.

[ Voor 40% gewijzigd door Woy op 03-07-2010 09:34 ]

[roy-t]

FragFrog schreef op zaterdag 03 juli 2010 @ 00:18:
[...]

Daar heb je een minor voor Besides, zo zwaar is'ie ook niet - ik heb in elk geval het eerste deel vrij eenvoudig naast m'n normale vakken kunnen volgen indertijd

Then again, ik heb afgelopen periode ook een vijf EC robotica practicum extra gevolgd, wellicht denk ik er wat makkelijk over

De C++ cursus telt alleen voor KI als minor, bij informatica mag je deze niet als minor doen .

(Wat deels ook wel logisch is, want de meeste KI-ers kunnen niet programmeren, vooral dat zooitje wat parallel computing mee doet/deed . Nu ken ik toevallig FragFrog en weet ik dat hij het wel kan )