mboost-dp1
SXC - clix
I fremtiden? Alt på denne liste er enten noget som man "bør have fokus på" nu, eller noget som kun er relevant på visse arbejdspladser.
Jeg ville dele det op nogenlunde på denne måde.
Ting praktisk talt alle udviklere bør have fokus på NU:
1: One of the “Big Three” (.NET, Java, PHP)
5: Soft skills
6: One dynamic and/or functional programming language
7: Agile methodologies
8: Domain knowledge
9: Development “hygiene”
Ting nogle udviklere får behov for, men som jeg ikke vil forvente at de sætter sig ind i før behovet er der:
2: Rich Internet Applications (RIAs)
3: Web development
4: Web services
10: Mobile development
Jeg ville dele det op nogenlunde på denne måde.
Ting praktisk talt alle udviklere bør have fokus på NU:
1: One of the “Big Three” (.NET, Java, PHP)
5: Soft skills
6: One dynamic and/or functional programming language
7: Agile methodologies
8: Domain knowledge
9: Development “hygiene”
Ting nogle udviklere får behov for, men som jeg ikke vil forvente at de sætter sig ind i før behovet er der:
2: Rich Internet Applications (RIAs)
3: Web development
4: Web services
10: Mobile development
0 skrev:10 ting udviklere bør have fokus på i fremtiden
Der menes vist "10 ting web-udviklere bør have fokus på i fremtiden"
ALLE ligefrem?
Hvad med os der ikke bruger .NET/PHP java og lign? Vi er faktisk mere end to.
Der sidder en del og laver C/C++ udvikling til både det ene og det andet, og som jeg ikke tror foreløbig vil have behov for at kigge på .NET/Java/PHP
Den liste i artiklen virker noget orienteret imod webudviklere. At At 5-9, så også gælder for os er da rigtig nok, men det er vel forventet af alle?
Hvavd med sådan noget som formelle metoder? Med større krav til leveringssikkerhed og ikke mindst at levere det speficere, får det vel også et revival ? Og med flere kerner i spil, så er det vel ved at et så stort behov for at kunne matematisk specificere og bevise udvalgte stykker af koden?
Og moderne ting såsom at kunne co-design/simulere soft og hardware/mekanik, bør man vel også have fokus på nu/i fremtiden?
Hvad med os der ikke bruger .NET/PHP java og lign? Vi er faktisk mere end to.
Der sidder en del og laver C/C++ udvikling til både det ene og det andet, og som jeg ikke tror foreløbig vil have behov for at kigge på .NET/Java/PHP
Den liste i artiklen virker noget orienteret imod webudviklere. At At 5-9, så også gælder for os er da rigtig nok, men det er vel forventet af alle?
Hvavd med sådan noget som formelle metoder? Med større krav til leveringssikkerhed og ikke mindst at levere det speficere, får det vel også et revival ? Og med flere kerner i spil, så er det vel ved at et så stort behov for at kunne matematisk specificere og bevise udvalgte stykker af koden?
Og moderne ting såsom at kunne co-design/simulere soft og hardware/mekanik, bør man vel også have fokus på nu/i fremtiden?
#3
Er ikke ret mange mennesker der laver hjemmesider i C/C++, og de der gør burde stede havde kendskab til en af de "big three".
Med mindre vi snakker web-services, og så er vi ovre i en anden boldgade.
Ellers er det ret specialiseret det i laver, og er uden for kategorien alligevel.
Er ikke ret mange mennesker der laver hjemmesider i C/C++, og de der gør burde stede havde kendskab til en af de "big three".
Med mindre vi snakker web-services, og så er vi ovre i en anden boldgade.
Ellers er det ret specialiseret det i laver, og er uden for kategorien alligevel.
#4
Har du læst mit indlæg? Jeg siger netop at listen kun giver god mening for webudviklere, jeg skriver ingen steder om at lave web lir i C eller C++. Min pointe var jo netop, at listen burde hedde for webudviklere, da vi er mange som aldrig rører ved web og slet slet ikke er i nærheden af at kunne bruge de 3 sprog.
Har du læst mit indlæg? Jeg siger netop at listen kun giver god mening for webudviklere, jeg skriver ingen steder om at lave web lir i C eller C++. Min pointe var jo netop, at listen burde hedde for webudviklere, da vi er mange som aldrig rører ved web og slet slet ikke er i nærheden af at kunne bruge de 3 sprog.
ja.. .NET er altså stadig ikke et programmeringssprog. Det er et framework.
Måske de hellere skulle sige: .NET enablede programmeringssprog som x, y, z.
Og PHP er heller ikke et programmeringssprog. Det er et script sprog i og med det er fortolket.
Onde tunger vil nok sige det samme om Javas bytecodes og .NETs IL. Men PHP har har ikke en JIT-compiler til mit kendskab ? Det er bare en fortolker?
Måske de hellere skulle sige: .NET enablede programmeringssprog som x, y, z.
Og PHP er heller ikke et programmeringssprog. Det er et script sprog i og med det er fortolket.
Onde tunger vil nok sige det samme om Javas bytecodes og .NETs IL. Men PHP har har ikke en JIT-compiler til mit kendskab ? Det er bare en fortolker?
lorenzen (6) skrev:#4
Har du læst mit indlæg? Jeg siger netop at listen kun giver god mening for webudviklere, jeg skriver ingen steder om at lave web lir i C eller C++. Min pointe var jo netop, at listen burde hedde for webudviklere, da vi er mange som aldrig rører ved web og slet slet ikke er i nærheden af at kunne bruge de 3 sprog.
Jeg vil blot påpege at .NET ikke er et sprog med et framework. Desuden kan .NET og Java vel bruges til andre ting end web-udviking.
Desuden kan agile tilgangen også bruges af andre end web-udviklere, så du har ikke ret i at listen kun er for web-udviklere.
Desuden er ordet "ting" i titlen forkert for det drejer sig vel om teknologier og praktiske metoder.
myplacedk (9) skrev:#7
the Big Three development systems — .NET (VB.NET or C#), Java, or PHP
Jeg synes nu deres mening fremgår ret tydeligt. De kalder det ikke et programmerings-sprog, og de viser at de bruger ".NET" som et paraply-begreb.
Han mener i den danske oversættelse på newz.dk, her bliver dette paraply-begreb ikke anvendt:
Blandt punkterne er der helt specifikke ting som at vælge en af de tre "store" programmeringssprog (.Net, Java og PHP)
Umiddelbart så synes jeg da den artikel minder folk om gode ting at have med i værktøjskassen. Om ikke andet så for unge udviklere på vej ud i verden. Jeg synes absolut ikke de bringer noget nyt på banen -- men det er sandsynligvis heller ikke hensigten.
Alt hvad de har nævnt bruger jeg i de fleste projekter (sans antallet af programmeringssprog etc.).
De burde nok sætte mere fokus på "When to use what and why?"
Jeg har en fornemmelse af at mange udviklere let bliver til nogle overivrige teknologionanister. Det er lige så vigtigt at vide hvornår du skal bruge et redskab, fremfor at bruge det bare fordi du har det. Jeg mener, en tømrer bruger heller ikke en sav til at hamre med bare fordi han kan?
Alt hvad de har nævnt bruger jeg i de fleste projekter (sans antallet af programmeringssprog etc.).
De burde nok sætte mere fokus på "When to use what and why?"
Jeg har en fornemmelse af at mange udviklere let bliver til nogle overivrige teknologionanister. Det er lige så vigtigt at vide hvornår du skal bruge et redskab, fremfor at bruge det bare fordi du har det. Jeg mener, en tømrer bruger heller ikke en sav til at hamre med bare fordi han kan?
jAST (7) skrev:Og PHP er heller ikke et programmeringssprog. Det er et script sprog i og med det er fortolket.
Nåh? Så ved jeg ikke lige hvad det er, de her laver:
http://www.roadsend.com
Og de andre sprog bliver ikke fortolket eller? Nåh - ikke mere flamebait ;-)
Min pointe er at ALLE de nævnte sprog kan bruges til at lave stand-alone applikationer! Så artiklen henvender sig OGSÅ til de udviklere, som ikke laver kode til det dersens indernet!
#16: ak toke.. alle kan jo ikke være så meget en php-hugging fanboy som du er :D Og jeg ville nok hellere voldtage mine indre organer med en rusten rive førend jeg begyndte at kode php, for derefter at kompilere det </joke>
Men jo, jeg skrev jo netop i min post at de blev fortolket for derefter at blive JIT compiled... men det gør PHP nu engang ikke. Ikke out of the box om ikke andet. Selvfølgelig kan man altid finde en gal fanboy [sic] som insisterer på at gøre det ;)
٩(●̮̮̃●̃)۶ ٩(•̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ ٩(●̮̮̃•̃)۶
Men jo, jeg skrev jo netop i min post at de blev fortolket for derefter at blive JIT compiled... men det gør PHP nu engang ikke. Ikke out of the box om ikke andet. Selvfølgelig kan man altid finde en gal fanboy [sic] som insisterer på at gøre det ;)
٩(●̮̮̃●̃)۶ ٩(•̮̮̃•̃)۶ ٩(-̮̮̃-̃)۶ ٩(●̮̮̃•̃)۶
gensplejs (18) skrev:eeeeeeP!
PHP FØJ!
Jeg vil hellere dø end lære et typeløst sprog.... FØJ for satan.
Fordi C++'s "void*" er en meget specifik type?
Java og C#'s "Object" er også utrolig specifik!
C# 4.0 kommer vist nok også til at indeholde en dynamisk type a la PHP! Og det er imho en forbedring, da det lige nu er et typecast-helvede at lave generelle algoritmer og bruge dem bagefter! Se evt. på "HashTable";
http://msdn.microsoft.com/en-us/library/system.col...
jAST (17) skrev:#16: ak toke.. alle kan jo ikke være så meget en php-hugging fanboy som du er :D
Var det så tydeligt... :-) Men jeg er nu også meget glad for C# - .NET freaking rulez!
jAST (17) skrev:Men jo, jeg skrev jo netop i min post at de blev fortolket for derefter at blive JIT compiled... men det gør PHP nu engang ikke. Ikke out of the box om ikke andet. Selvfølgelig kan man altid finde en gal fanboy [sic] som insisterer på at gøre det ;)
Jeg insistere overhovedet ikke på at gøre det - nævner bare at det er muligt!
lorenzen (21) skrev:Du kan ikke bare tage og pege på c++ og sige der findes void, og dermed er det lige så grimt. Hvertfald kan jeg ikke helt følge dit ræsonement. Måske du kan uddybe?
Ikke void, men void pointer (hint: asterix)! En void pointer er en pointer til en udefineret type... Så hvis en funktion eller metode returnerer en void pointer, har du som programmør ingen anelse om hvilken type der peges på - præcis ligesom Object i Java og C#. Igen er typecasting nødvendigt. Det er det ikke i PHP (eller JavaScript for den sags skyld)
Men det er en fin feature, hvis den bliver brugt ordentligt.
Min pointe er dog at nogle problematikker bliver løst væsentligt mere elegant i PHP frem for "typestærke" sprog. Omvendt har disse nogle andre fordele, som PHP ikke har - eksempeltvis kørselshastighed, hukommelsesforbrug, pladsforbrug, grafisk performance osv osv ...
Jeg er udemærket godt klar over hvad en void pointer er, jeg undrede mig mest af alt over dit ræsonement. Bruger den faktisk i flere tilfælde, ikke at det er kønt, men det virker godt de steder jeg har behov for det. Det hænder.
Så ja, det er en fin feture, hvis man bruger den når den skal bruges. Og dermed er vi igen henne ved jeg ikke helt ved hvor du vil hen med dit indlæg.
Så hvis du evt. kunne uddybe php's mere elegante løsning kunne det være rart, jeg har ikke den store dybdte gående viden om php så det ville jeg gerne høre mere om.
Så ja, det er en fin feture, hvis man bruger den når den skal bruges. Og dermed er vi igen henne ved jeg ikke helt ved hvor du vil hen med dit indlæg.
Så hvis du evt. kunne uddybe php's mere elegante løsning kunne det være rart, jeg har ikke den store dybdte gående viden om php så det ville jeg gerne høre mere om.
lorenzen (23) skrev:Så hvis du evt. kunne uddybe php's mere elegante løsning kunne det være rart, jeg har ikke den store dybdte gående viden om php så det ville jeg gerne høre mere om.
Har du forsøgt at lave en hashtabel i C++ (uden at bruge templates, fordi du får typen runtime!)? Array, lister og hashtabeller er præcis det samme i PHP. Iterering er dermed uhyggeligt trivielt - det er det så vidt jeg husker ikke i C++. Og det er ydermere ligegyldigt hvilken type objekterne har da typecasting bliver udført automatisk...
For at opsummere for dig: void* er "typeløs", hvilket var min oprindelige pointe.
Desuden kan void* også benyttes som functor, altså en pointer til en funktion, hvilket slører gennemskueligheden yderligere!
Du har da ret i at hvis man ikke bruger STL så er, det noget mere bøvlet i C++. Men hvorfor skulle man ikke bruge boost/STL/Qt? Ellers kan jeg vel bare lave min egen STL implementeirng og så er vi jo lige vidt.
Og void pointeren kan mange ting, det er derfor den er så super. Men igen, du får det til at lyde som noget negativt at C++ har en void pointer. Er det ikke netop positivt, at man har sørget for at levere en super hammer, til de få tilfælde den skal bruges?
Det er stadigvæk der jeg ikke kan følge dig, havde man i PHP haft mulighed for at bruge en eller anden feature, så er det da ikke negativt, så længe man bruger den efter hensigten. Alt kan misbruges og bliver det også., men det jo udvikleren den er gal med og ikke sproget.
Så du bringer void pointeren op fordi du mener det er negativt, eller bare for at illustrere at c++ er så gennemtænkt at der er mulighed for at bruge void pointer når det ønskes? Eller ville du bare gerne konstatere at vi har en void pointer i c++, og som jeg kan forstå noget cirka tilsvarende i Java og C#.
Og void pointeren kan mange ting, det er derfor den er så super. Men igen, du får det til at lyde som noget negativt at C++ har en void pointer. Er det ikke netop positivt, at man har sørget for at levere en super hammer, til de få tilfælde den skal bruges?
Det er stadigvæk der jeg ikke kan følge dig, havde man i PHP haft mulighed for at bruge en eller anden feature, så er det da ikke negativt, så længe man bruger den efter hensigten. Alt kan misbruges og bliver det også., men det jo udvikleren den er gal med og ikke sproget.
Så du bringer void pointeren op fordi du mener det er negativt, eller bare for at illustrere at c++ er så gennemtænkt at der er mulighed for at bruge void pointer når det ønskes? Eller ville du bare gerne konstatere at vi har en void pointer i c++, og som jeg kan forstå noget cirka tilsvarende i Java og C#.
lorenzen (25) skrev:Så du bringer void pointeren op fordi du mener det er negativt, eller bare for at illustrere at c++ er så gennemtænkt at der er mulighed for at bruge void pointer når det ønskes? Eller ville du bare gerne konstatere at vi har en void pointer i c++, og som jeg kan forstå noget cirka tilsvarende i Java og C#.
Præcis! Det er slet ikke ment negativt - den er fakkertalt mega smart!
Den har bare ikke nogen type - den er "de facto" alting, da den basalt set bare er en hukommelsesadresse. Hvilket efter min mening gør det uigennemskueligt. Men "Obfuscated code" er selvfølgelig også en kodestil... :-)
http://en.wikipedia.org/wiki/Obfuscated_code
Nu har vi vist bevæget os tilstrækkeligt langt væk fra artiklens indhold, så skal vi ikke bare stoppe den her eller fortsætte udenfor denne tråd.
TokeBoy (19) skrev:
C# 4.0 kommer vist nok også til at indeholde en dynamisk type a la PHP! Og det er imho en forbedring, da det lige nu er et typecast-helvede at lave generelle algoritmer og bruge dem bagefter! Se evt. på "HashTable";
http://msdn.microsoft.com/en-us/library/system.col...
Hm.
Det problem blev altså løst i .NET 2.0 for ca. 4 år siden.
#Lorenzen
Forstå nu at ecmascript SAGTENS kan lave 3D, SDR osv! DET ER DET FAKTISK BEDST TIL! ALLE, ja, ALLE DSP'er er nemlig implementeret i en eller anden ecmascript implementering!
#diverse
Nogle burde læse deres sprogspecifikationer, især når det gælder void, Object osv. Eller bare kende deres API'er og frameworks
@subject
Listen er sådan set fin nok; langt størsteparten af udviklere sidder jo og laver MOSS, web eller lign. idag. Det kan man så mene om hvad man vil, men sådan ligger landet jo. Og fint nok, så kan vi andre jo nemmere få jobs når alle følger lister som den der :D
Forstå nu at ecmascript SAGTENS kan lave 3D, SDR osv! DET ER DET FAKTISK BEDST TIL! ALLE, ja, ALLE DSP'er er nemlig implementeret i en eller anden ecmascript implementering!
#diverse
Nogle burde læse deres sprogspecifikationer, især når det gælder void, Object osv. Eller bare kende deres API'er og frameworks
@subject
Listen er sådan set fin nok; langt størsteparten af udviklere sidder jo og laver MOSS, web eller lign. idag. Det kan man så mene om hvad man vil, men sådan ligger landet jo. Og fint nok, så kan vi andre jo nemmere få jobs når alle følger lister som den der :D
Det er ikke synderligt overraskende at de gerne vil have at vi fokusere vores skills på at kunne lave applications til web/cloud systemer.
Fra thin-clients (70er style), til thick-clients (90er style), er vi nu tilbage ved thin-clients igen :-)
Og ja, at lære et funktioneltsprog for at kunne udnytte flere kerner er et absolut must. Ikke fordi jeg har lyst til det, men det ville være ret fornuftigt at lære f.eks. Haskell.
Fra thin-clients (70er style), til thick-clients (90er style), er vi nu tilbage ved thin-clients igen :-)
Og ja, at lære et funktioneltsprog for at kunne udnytte flere kerner er et absolut must. Ikke fordi jeg har lyst til det, men det ville være ret fornuftigt at lære f.eks. Haskell.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund