Vilket (programmerings) språk och böcker bör man läsa om? Framtids säkert!

[quote=Tooner]Va? Ge ett exempel där Java har mycket mer kod än motsvarande C-program (eller assembler eller vad det nu är du förespråkar).

Jag förespråkar inget språk, till skillnad från er. Jag försöker bara se objektivt på allting och därmed pekar ut brister med vissa språk.


Typiska bortförklaringen ni jämt kommer med. "Det spelar ingen roll om det suger, för är man grym så blir det rätt!". Bara bortförklaringar.


Det låter ju jättebra att man ska behöva göra det menar du?


Har skrivit det redan. Har man en jädra massa klasser och ska flytta funktionaliteten runt mellan dem, så är det ju nästan oundvikligt att åka på buggar.


I Java så finns ju inte ens konstanter, hört talats om const-correctness? Sun i egen hög har ju erkänt att det aldrig kommer att finnas.


Jag kan dra slutsatsen att du är en insnöad JAVA-programmerare utifrån denna tråd. Säger detsamma, du kan ju fortsätta leva i din sagovärld där OOP är bäst till allting och Java är bäst.


Varför rekommenderar du Java före många andra språk? För det första så är man bara begränsad till OOP, för det andra så är allting bara en stor kaotisk samling av klasser och bibliotek.

Tycker det är precis tvärtom , genom att dela upp programmet i olika välspecificerade undviker man buggar. Har man en kaotiskt röra av olika klasser där det inte är specificerat exakt vad varje metod gör så ja det kan bli rörigt men det är samma problem som fås oavsett OOP eller ej om man inte dokumenterar sin kod.

Ni här inne som hävdar att OOP suger. Ni vill kunna lägga era funktioner var och hur ni vill.
(Påminner mig om tiden med QuickBasic och dess subrutiner).

Jag är medveten om att det har väckts en seriös debatt kring OOP även på andra platser, men skulle ni kunna förtydliga vad den går ut på?

1. Pratar ni om att skita i klasser och objekt? Ni slutar instansiera klasser. Kopplar ihop stora filer med funktioner och har en stor main(); där hela programflödet ligger. Hittar på er egen struktur för varje applikation ni bygger.

Eller

2. Pratar ni om att inte "overdo" OOP? Ni accepterar klassfenomenet med metoder och respekterar en del grundläggande fenomen som inkapsling. Men ni undviker onödigt långa arvstrukturer och kanske sneglar på GoF ibland?

Vad är det ni förespråkar istället? Alltid skrivs det om alternativ till oop. "Du vet väl att det finns alternativ?", men inte vad. Upplys mig!

Tror knappast någon är ute efter något sådant. Det behöver inte vara svart och vitt.

Vad är det ni förespråkar istället? Alltid skrivs det om alternativ till oop. "Du vet väl att det finns alternativ?", men inte vad. Upplys mig![/quote]

OOP i sig är det inget fel med, det finns ju såklart många saker OOP lämpar sig bra till. Fast enkapsulation är exempelvis inte unikt för OOP heller, utan det finns abstrakta datatyper i funktionella språk som ML och Haskell.

Vill man koda OOP så verkar F# vara riktigt lovande språk. Java i sig ska man dock hålla sig borta från utifrån allt jag har snappat upp om det.

Du menar hittar på brister som inte finns? (eftersom du uppenbarligen inte har något exempel där Java behöver mer kod för samma uppgift)


Vadå "behöver" göra?

Jag börjar mer och mer tro att du är totalt okunnig inom programmering i allmänhet och objektorienterad programmering i synnerhet.

Att skriva en utility-klass tar 2 rader "extra" kod, och med ett väl valt klassnamn får du en tydlig samlingsplats för alla metoder som annars antagligen skulle ligga och skräpa på alla möjliga platser i programmet.

Du har ingen aning om vad jag menade va? Du hörde "utility-klass" och antog att det var något jobbigt. Precis som du hört "objektorienterad" och antar att det inte är värt något.


Herregud...

"Flytta funktionaliteten mellan dem"??

Du låter precis som snorungarna på gymnasiet. "Åhhh det är så jobbigt att skriva objektorienterat, varför kan inte alla funktioner och variabler vara public? Då slipper man hålla på å tänka..."

Och som jag och andra redan nämnt minskar OOP antalet buggar och eftersom OOP gör modulär programmering nästan svår att undvika så kommer de buggarna som ändå uppstå vara mycket lättare att hitta och åtgärda.


Men? Du kastar ur dig uttryck som inte har någon mening bara för att låta som du vet vad du pratar om.

Om du deklarerar en variabel "final" i Java så är det samma sak som att deklarera den "const" i C.

Och som jag redan sagt går det att skriva sin kod så att den får samma funktion som "const", (även i datatyper etc. där "final" inte fungerar på samma sätt).


Jag drar slutsatsen att du är helt okunnig och har hittat nån "alla-fel-med-Java"-sida som du spyr dina påståenden från.


Du väljer att påstå att OOP är något negativt och en "begränsning". Det finns inte många seriösa programmerare som håller med dig om det.

Eftersom OOP är viktigt och nyttigt, särskilt för nybörjare, så är Java ett perfekt språk att börja med.

C# går också bra av samma anledning, men jag tycker, till skillnad från dig igen att Java's stora klassbibliotek (som också kan användas som referens för egna klasser) är en stor tillgång, så därför kommer Java lite före i min rekomendation.

Jag kanske skulle posta koden till mitt tetris-spel som jag skrev för ett par år sedan, 1500+ rader kod i en fil, inte en enda klass eller metod, med andra ord så långt ifrån OOP det bara kan bli. Så kan någon få fixa en bugg eller något, det borde ju vara jättelätt med tanke på att det är inte objektorienterat

Personligen tycker jag inte att det är nödvändigt att ha Bjarnes bok bokhyllan även om jag själv har den. "C++ Programming Language" är främst tänkt att användas som referensmanual och då kan man egentligen direkt hoppa på ISO/IEC 14882:2003.

Du kommer i vilket fall som helst inte att ångra dina val.

Steve McConnell's "Code Complete" är starkt rekommenderad läsning senare när du väl ha börjat behärska språket.


Både OOP och Procedurell Programmering kräver en viss förmåga från programmeraren för att koden ska förbli lätt att modifiera, utöka och testa/debugga. Vad OOP gör i många fall är att sänka erfarenhetströskeln och även låta lite mindre disciplinerade programmerare skriva kod som uppfyller dessa krav.

Inkapsling är t.ex. långt ifrån unikt för OOP, men per design gör OOP att man ej till skillnad från PP behöver sätta upp riktlinjer för hur man ska koda för att se till att inkapsling sker. Situationen är mycket snarlik den med Garbage Collectors. Förutom för vissa mindre vanliga fall med cirkulära beroende så räcker det med att man använder sig av shared_ptr överallt i C++ för att "garantera" att bli av med alla minnesläckor - men utan GC:s måste man sätta upp dessa riktlinjer och därmed sätts lite mer press på programmeraren.


Och exakt varför behöver man konstanter annat än för dem mest grundläggande typerna (i.e. POD-typer) och möjligen även för kontainrar (alternativt göra dem oförändliga)? Bli koden enklare att underhålla om man kan göra en "konstant" ModalWindow eller SwordItem?


Nu var inte frågan riktad mot mig men jag står personligen på samma sida som de som håller på punkt 2.

Som Jeff Atwood skrev på Coding Horror: "Not that object oriented programming is inherently bad, mind you, but a little OOP goes a very long way. Adding objects to your code is like adding salt to a dish: use a little, and it's a savory seasoning; add too much and it utterly ruins the meal."

Jag har skrivit mycket C++-kod som egentligen bör klassas som "C-kod med STL kontainrar" istället. GUI är ett annat område där OOP verkligen skiner.


Tekniskt sett anser jag inte "utility-klasser" för att vara av riktig OOP-design. De fungerar som work-arounds för att man i Java måste lägga allt i klasser (i.e. klassen används här som motsvarigheter till namnrymder i C++). Men det betyder å andra sidan att jag instämmer med grundtanken bakom ditt svar; påståendet att man "bara måste" programmera OOP i Java är egentligen väldigt löjligt.


Man får dock inte glömma att OOP är långt ifrån någon universallösning. OOP är vettig om det är rimligt att sätta objekten i fokus (duuhhhh!) men för allt annat (säg, affärslogiken i sig och inte "Customer"-klassen?) så kommer man bara att drabbas av "OOP-skatten". D.v.s. att man spenderar en avsevärd mängd tid på "stöd-kod" jämfört med vanlig PP-kod.


vs


(okay, det var ett löjligt exempel, men jag hoppas att du ändå förstår vad jag försöker få sagt )

Ett programmeringsspråk är bara ett verktyg, man väljer verktyg efter uppgiften och dess krav. Att slå in en spik med en skruvmejsel är inte särskilt lyckat, och har man bara en hammare så ser alla problem ut som spikar.

Att säga ETT språk idag som ska vara framtidssäkert är svårt. Språkutvecklingen går framåt, det språket som är på tapeten idag kan vara omodernt imorgon. Om man jobbar i 40 år som programmerare så kommer man nog "tvingas" att lära sig x antal språk under sitt yrkesliv. Sen finns det så klart språk som stått emot tidens tand bättre än andra, "systemspråk" som t.ex. C/C++ är exempel på detta. Men majoriteten av den "vanliga programmeringen" sker i språken som är "inne" just nu, för tillfället så är det C#/Java som gäller om man tittar på jobbannonserna.

Som några andra redan sagt tidigare i tråden: lär dig inte ett programmeringsspråk utan lär dig att programmera.

(Och fundera inte så mycket över "första språket", det blev ju folk av BASIC-programmerarna till slut också! )

[quote=Tooner]Du menar hittar på brister som inte finns? (eftersom du uppenbarligen inte har något exempel där Java behöver mer kod för samma uppgift)

Du påstår exempelvis att typsystemet inte är något brist alltså? Det är klart att Java behöver mer kod för samma uppgift när man måste kapsla in allting i en massa klasser, till och med fristående funktioner. Hur kan detta undgå dig?


Skapa en massa utility-klasser för att det inte går att skapa fristående funktioner. Förstår inte hur man kan påstå att det är bra att man måste skapa klasser med en massa statiska funktioner.


Tydlig samlingsplats som kanske inte ens är tydlig eftersom alla funktioner inte nödvändigtvis bör vara i samma klass.





Ingen aning om vilka du snackar om, men det är väl snarare du som besitter sådan mentalitet.
Det lustiga med din stolthet över Java = OOP, är att det inte ens har multipelt arv eller operator överlagring. Många av de saker du förespråkar kan också diskuteras om de går emot OO-design eller inte.


Modulär programmering är inget som är unikt för Java. Förresten så misslyckas Java även på det. Ta exempelvis en titt på denna sida: http://warp.povusers.org/grrr/java.html


I lol'd. Åter igen ett bevis på att du inte vet vad du pratar om.


Faktum kvarstår att det inte finns konstanter i Java.


Spelar ingen roll vilken slutsats du drar (då den tydligen verkar vara ganska bristfällig). Utan jag försöker bara förmedla brister, som du bölar för att jag påpekar. Irrelevant vad som är orsaken till vad och vad du tycker om mig, faktum är fortfarande faktum.


Åter igen falska föreställningar som du inbillar dig. Jag har inte skrivit att OOP är negativt eller är en begränsning. Jag har skrivit att OOP inte alltid är optimalt? Man bör lära sig alla paradigmer. Sedan dina "det finns inte många seriösa programmerare som håller med dig" är ju det lägsta man kan komma med.

Hoho, jag känner 100 säkerhetsexperter som säger att man inte ska låsa ytterdörren. Så det så

-----------------------------


Precis.
Sedan... löjligt kan det låta, men det ändrar inte bristerna.

Multipla arv är ett otyg och utvecklarna av Java valde helt rätt när de inte la till det (det var ett genomtänkt val ja, inte något som glömdes bort eller vad du nu tror). Snacka om att få svårläst kod, du som hatar OOP så innerligt.

På samma sätt undviker man att koden blir svårläst genom att inte tillåta överlagring av operatorer, dessutom finns det knappast några direkta fördelar med funktionaliteten ändå. (och även det är ett val som gjorts, inte något som glömts bort)

Jaja, nu börjar troll-smileysarna komma så dags att sluta lägga energi på ännu en mupp.

Du får det att låta som om bristerna vore enorma. Ta exemplet med "const" igen. Jag ställer om min tidigare fråga: Och exakt varför behöver man konstanter annat än för dem mest grundläggande typerna (i.e. POD-typer) och möjligen även för kontainrar (alternativt göra dem oförändliga)? Bli koden enklare att underhålla om man kan göra en "konstant" ModalWindow eller SwordItem?


One size does not fit all.

http://www.parashift.com/c++-faq-lit....html#faq-25.2




Argumenten för operatoröverlagring är avsevärt svagare än dem för multipelt arv. Jag skulle till och med vilja påstå att fördelarna där är långt större än nackdelarna, om programmeraren har något som helst vett i huvudet alls.

Man behöver inte kika längre än till Javas BigInteger/BigDecimal för att hitta ett fall där avsaknaden av operatoröverlagring gör bibliotetekt avskyvärd att använda.

Nä visst, det finns naturligtvis tillfällen då multipla arv kan vara nyttigt, om programmeraren vet vad han gör.

Det går alltid att tycka att en viss funktion ska finnas. Pekare har ju också sin nytta till exempel. Att själv frigöra minne istället för att låta en garbage collector göra det är ett annat exempel.

En grym programmerare som vet exakt vad han håller på med, har obegränsat med tid och tycker att minsta lilla beståndsdel är viktigt, tycker antagligen att assembler är det bästa sättet att programmera. Där finns inga begränsningar, du kan bygga precis hur du vill.

Vill du däremot programmera effektivt och skapa kod som andra, oinsatta, programmerare ska kunna ta del av så är vissa restriktioner till stor nytta istället.

Nyttan av multipla arv kan diskuteras, min åsikt är att de gör mycket mer skada än nytta. Men poängen är att de valdes bort ur Java på grund av problemen de medför, det är inte en begränsning av Java utan ett genomtänkt designval.