Hvilke programmerings språk kan dere?

[sinnaelgen]

Da høres det nesten ut som også dette språket er på vei til å avgå med døden selv om det høres lit interessant ut.

 

en funksjon/ mulighet som inline assembler har jeg regnet de flest språk har , er det riktig ?

( mener å kjenne det igjen fra pascal / delphi)

 

når du bruker begrepene "DMD" og "GDC) er det navnet på kompilatoren(e) som brukes til dette språket ?

 

 

 

jeg vet ikke om det er gjort før , men jeg savner en oversikt over hvor man kan få tak i ( enten å kjøpe eller å laste ned) det forskjellige programmeringsspråkene.

 

Det som virker lit synd her er at hvis jeg skal ta statistikken (linket til i et innlegg lenger oppe ) på alvor så virker det som meste parten av programmeringsspråkene er døde. dette får meg til å stusse lit om denne statistikken dier den fulle sannheten når mesteparten av språkene har under 2 % av brukerne. det tilsvarer ( etter min beregning ) 120 millioner brukere hvis verden består av 6 milliarder mennesker

delphi har da ca 100 millioner brukere.

det forsvarer dog ikke det faktum at de priser seg ut av markedet

 

min definisjon av at død program i denne sammenhengen er at språket er død når det bare har noen tusen brukere

Endret 1. desember 2010 av den andre elgen

[GeirGrusom]

Inline assembly var mer vanlig før. C++, Pascal og Delphi har det. Ulempen er at C++ har det som en frivillig utvidelse, som fører til at implementasjonen er forskjellig i forskjellige kompilatorer. Visual C++ bruker MASM syntaks.

 

DMD og GDC er kompilatorer ja. DMD er Digital Mars sin kompilator (han som laget D sin egen implementasjon) og GDC er GCC (Gnu Compiler Collection) sin implementasjon.

 

Du må ta den listen med en neve salt som sagt, men den viser nok den generelle trenden. Hvordan tallene er kommer an på datakilden. Jeg synes andelen til Java virker noe overdrevet der.

 

Delphi har et problem med at de må konkurrere ved å selge et verktøy du finner gratis hos konkurrentene. Microsoft gir ut gratisversjoner av Visual Studio (Express versjonene) som er fullt på høyde med Delphi i muligheter, men koster deg ikke en eneste krone.

 

Det er særdeles viktig at det språket du bruker faktisk er i utstrakt bruk. Det gjør det enklere å finne løsninger på problemer, biblioteker og folk som faktisk har kunnskap til å hjelpe deg hvis du sitter fast på noe. Dersom du sitter i Prolog, Delphi, D, Turbo Pascal eller Turtle, er det mye vanskeligere å finne noen som er istand til å hjelpe deg.

[sinnaelgen]

hvis jeg "maser" for mye om C , og hvordan man gjør den minste ting så er jeg redd for at det blir oppfatte som for mye mas.

De som da kan hjelpe går da lei.

så da kan dette slå begge veier.

 

er språket for nytt så er det nok ikke mange som kan det og man får ikke hjelp.

er det for gammel så blir nok problemet det samme

[GeirGrusom]

Tja, jeg ville trodd at dersom du har en stor brukermasse å ta av, vil alltid noen komme å hjelpe deg videre hvis de andre går lei. C er jo et språk de aller fleste kan, selv om de kanskje ikke bruker det daglig.

C# er kanskje litt annerledes, men det har en ganske stor brukermasse.

[-kga-]

Har man lært et språk så er det ofte rimelig lett og sette seg inn i ett annet som er byggd opp på de samme paradigmene siden logikken bak dem er rimelig lik. Og om språket men vil lære i tillegg er på ett høyere abstrakt nivå en det lignende språket man kan så blir det enda enklere (andre veien er litt vanskeligere). Kan man feks c++ er det lett og lære seg språk som java eller python.

 

Det vill riktig nokk være en stund(flere månedre) som ting tar litt lenger tid siden man jevnlig/oftere må slå opp på Internet for en rekke småting, men ofte er det fint mulig og sette igang med å lage de programmene du ønsker etter ett parr dager, og ofte kortere.

 

Jeg syntes en CV som forteller om god kunnskap innen flere språk som er veldig forskjellige er bedre en en som har tre ganger så mange språk men hvor alle er nesten like hverandre.

 

En god å dyp forståelse om så mange som mulig algorithmer og datastrukturer er etter min mening mye viktigere en å kunne ett språk så godt att du nesten aldri trenger å slå opp for ting du lurer på angående språket.

[GeirGrusom]

Det spørs jo helt hva du driver med. Forskjellige algoritmer har forskjellige mål, og de mest generelle algoritmene er sannsynligvis allerede implementert som en del av standardbiblioteket til språket du jobber med.

Det er lite poeng i å kunne alle mulige algoritmer for kollisjonsdeteksjon dersom du skal drive med et statistikkprogram. Det hjelper deg ingenting.

 

Etter min mening er det alfa-omega at du forstår språket du jobber med så forbanna godt som overhode mulig. Jo bedre du forstår språket du kan, dess bedre er du istand til å implementere optimale løsninger. Algoritmer er noe du kan slå opp. Vettig bruk av programmering, og et programmeringsspråk er noe du lærer deg.

 

For eksempel ser du at Java programmerere som går over til C# fortsetter å skrive Java kode i C#, til tross for at det finnes langt mer optimale løsninger i C#. Eksempelvis kan de fortsette å bruke get-ere og set-ere til tross for at C# har properties som er vesentlig enklere i bruk, og som er mye raksere (pga inlining)

Lambdauttrykk og LINQ kan også spare deg for side opp og side ned med kode, men ettersom svært få andre språk faktisk har denne muligheten, er dette noe en må lære seg å bruke, og forstå NÅR en kan bruke det.

 

Programmering handler om forståelse, ikke å slå opp algoritmer eller funksjoner.

[snippsat]

Etter min mening er det alfa-omega at du forstår språket du jobber med så forbanna godt som overhode mulig. Jo bedre du forstår språket du kan, dess bedre er du istand til å implementere optimale løsninger. Algoritmer er noe du kan slå opp. Vettig bruk av programmering, og et programmeringsspråk er noe du lærer deg.

 

For eksempel ser du at Java programmerere som går over til C# fortsetter å skrive Java kode i C#, til tross for at det finnes langt mer optimale løsninger i C#. Eksempelvis kan de fortsette å bruke get-ere og set-ere til tross for at C# har properties som er vesentlig enklere i bruk, og som er mye raksere (pga inlining)

Enig i dette,når man skifter språk så kan man ta med mange vaner som er normalt i det språket,men som kan være helt feil måte og gjøre ting på i det nye språket.

Som er påpekes godt i denne artiklen python is not java

 

bruke get-ere og set-ere til tross for at C# har properties

Som du nevner get-ere og set er normalt i java,men ikke i python og C#

Getters and setters are evil. Evil, evil, I say! Python objects are not Java beans. Do not write getters and setters. This is what the 'property' built-in is for. And do not take that to mean that you should write getters and setters, and then wrap them in 'property'. That means that until you prove that you need anything more than a simple attribute access, don't write getters and setters. They are a waste of CPU time, but more important, they are a waste of programmer time. Not just for the people writing the code and tests, but for the people who have to read and understand them as well.

 

Man må forandre tankegang.

This is only the tip of the iceberg for Java->Python mindset migration, and about all I can get into right now without delving into an application's specifics. Essentially, if you've been using Java for a while and are new to Python, do not trust your instincts. Your instincts are tuned to Java, not Python. Take a step back, and above all, stop writing so much code.

Endret 2. desember 2010 av SNIPPSAT

[sinnaelgen]

jeg er nå på om man ikke også vil komme over forstyrrende elementer her .

altså hvis man er vant med å gjøre tingen på en måte med et programgrinespråk for å oppnå best mulig struktur i programmet .

når man så går over til et annet så er strukturen så til de grader forskjellig at man detter av laset.

slik oppfatter i hvertfall jeg det hvis jeg går fra pscal til C* ( husker ikke om det er C,C++ , C# eller en annen variant)

 

strukturen mellom C ( en eller annen variant) og pascal virker ikke å være så veldig stor , men det med disse parantesene virker noe unødig forstyrrende.

 

 

var det ikke slik C språket manglet nesten alt av tekst og streng behandling , noe som bl.a. pascal har mye av ?

hvordan overkammer man det i C* ?

[GeirGrusom]

Strengbehandling er ikke videre enkelt i C nei. Det blir litt enklere i C++, men fortsatt er det vanskelig.

I C#, Python og Java er det derimot temmelig enkelt. Standardbibliotekene har funksjoner for regulære uttrykk lett tilgjengelig, og alt annet en kan trenge.

[snippsat]

Strengbehandling i python en rask intro.

I forhold til strengbehandling i C er dette mye enklere.

Noe av det fine python er at man teste ut hvordan ting virker live i IDLE.

Laste ned python 2.7 og kjøre igjennom dette tar ikke mere en 10-15min,for en som ikke har brukt python før.

>>> #En rask intro til python sin strengbehandling
>>> s = 'Hello world'
>>> dir(s)
'capitalize', 'center', 'count', 'decode', 'encode', 'endswith',
'expandtabs', 'find', 'format', 'index', 'isalnum', 'isalpha',
'isdigit', 'islower', 'isspace', 'istitle', 'isupper', 'join',
'ljust', 'lower', 'lstrip', 'partition', 'replace', 'rfind',
'rindex', 'rjust', 'rpartition', 'rsplit', 'rstrip', 'split',
'splitlines', 'startswith', 'strip', 'swapcase', 'title', 'translate', 'upper', 'zfill'

>>> #Her ser vi alle streng metoder
>>> #Vi kan bruke help
>>> help(s.upper)
Help on built-in function upper:
upper(...)
   S.upper() -> string    
   Return a copy of the string S converted to uppercase.

>>> #Teste den ut
>>> s.upper()
'HELLO WORLD'

>>> help(s.replace)
Help on built-in function replace:
replace(...)
   S.replace(old, new[, count]) -> string

   Return a copy of string S with all occurrences of substring
   old replaced by new.  If the optional argument count is
   given, only the first count occurrences are replaced.

>>> #Teste den ut
>>> s_new = s.replace('world', 'sweetheart')
>>> s_new
'Hello sweetheart'
>>> s_new.count('e') #Count teller anntall bokstaver av "e"
4

>>> s_new.endswith('sweetheart') #startswith(),endswith() return True False
True

>>> #Man kan bruke + og * på strenger
>>> t = ' you look nice'
>>> s_new + t
'Hello sweetheart you look nice'

>>> s_new * 10
'Hello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheartHello sweetheart'

#Avslutter med og telle forekomst av alle bokstaver
>>> from collections import Counter
>>> Counter(s_new)
Counter({'e': 4, 'l': 2, 't': 2, 'a': 1, ' ': 1, 'H': 1, 'o': 1, 's': 1, 'r': 1, 'w': 1, 'h': 1})

Endret 3. desember 2010 av SNIPPSAT

[Johan]

 

Etter min mening er det alfa-omega at du forstår språket du jobber med så forbanna godt som overhode mulig. Jo bedre du forstår språket du kan, dess bedre er du istand til å implementere optimale løsninger. Algoritmer er noe du kan slå opp. Vettig bruk av programmering, og et programmeringsspråk er noe du lærer deg.

 

 

Nåvel, det er jo klart viktig at man klarer å skrive nogenlunde ideomatisk kode, men jeg vi si det er mye mye viktigere å bruke, eller i det hele tatt å vite om, vel egnede algoritmer og datastrukturer. Og dette er ikke noe man "slår opp". Dette er noe man må kunne fra før av. Selv om jeg kan ideomatisk C# til fingerspissene så hjelper ikke det meg det spøtt om jeg bruker en lenket-liste der et vanlig array hadde vært riktig i en kritisk løkke, eller prøver å parse HTML eller XML med regulære uttrykk. Da går det i dass, om det så er med LINQ og lambdaer eller et helvetes switch-monster spiller liten rolle gitt...

 

Derimot har de fleste programmeringsspråk lignende trekk, og kan man et innenfor samme paradigme er det mye felles. Jeg kan like gjerne slå opp i spesifikasjonen til det programmeringspråket jeg måtte skrive i til enhver tid, noe jeg faktisk gjør, for å se hva syntaksen for f.eks arv heter nåtildags osv. Konseptet er akkurat det samme, og de finere detaljene står forhåpentligvis i spesifikasjonen.

[sinnaelgen]

hvis jeg kommer med kodelinjer ( jeg her temmelig mange ) fra Delphi/ pascal kan dere da hjelpe meg med å oversette dem til et annet programmeringsspråk ?

[-kga-]

Det spørs jo helt hva du driver med. Forskjellige algoritmer har forskjellige mål, og de mest generelle algoritmene er sannsynligvis allerede implementert som en del av standardbiblioteket til språket du jobber med.

Data structurer som: Linked list, vectors, priority queue, queue, stack, hash maps, er riktignok ofte implementert fra før av, men det er kjekt og vite når man burde bruke hva. Heldigvis hvet antagelig de fleste det når det gjelder disse data strukturene.

 

Etter min mening er det alfa-omega at du forstår språket du jobber med så forbanna godt som overhode mulig. Jo bedre du forstår språket du kan, dess bedre er du istand til å implementere optimale løsninger. Algoritmer er noe du kan slå opp. Vettig bruk av programmering, og et programmeringsspråk er noe du lærer deg.

 

For eksempel ser du at Java programmerere som går over til C# fortsetter å skrive Java kode i C#, til tross for at det finnes langt mer optimale løsninger i C#. Eksempelvis kan de fortsette å bruke get-ere og set-ere til tross for at C# har properties som er vesentlig enklere i bruk, og som er mye raksere (pga inlining)

Lambdauttrykk og LINQ kan også spare deg for side opp og side ned med kode, men ettersom svært få andre språk faktisk har denne muligheten, er dette noe en må lære seg å bruke, og forstå NÅR en kan bruke det.

 

Programmering handler om forståelse, ikke å slå opp algoritmer eller funksjoner.

Er selvsakt et stort pluss ok kunne språket ut og inn, men jeg mener nå det er viktigere og kunne algorithmer en å kunne en mengde forskjellige språk ut og inn. Hoved grunnen for å lære ett nytt språk burde være enten att man trenger det i jobb sammenheng, eller til eget prosjekt hvor det språket er desidert best til den aktuelle oppgaven (og man kan ingen andre som ligger like bak), eller at logikken bak det er såpass anderledes så man lærer en ny måte og tenke på når man lærer seg språket.

 

.. Algoritmer er noe du kan slå opp...

Hvis du ønsker ett raskt program så er det ikke alltid nokk å bare slå opp. Du må også vite når du skal bruke hva(feks. med tanke på tid, plass osv.), og ofte må du også tilpasse deler av algorithmen til ditt problem(feks. heuristic).

-Det å velge en god heuristic for et heuristic søk er ikke så lett å bare slå opp (med mindre du har ett klassiskt problem). Med en dårlig heuristic så kan man risikere at søket tar mange ganger så lang tid, noe som er et stort problem om n er stor.

- Om man kan gjenkjenne om et problem kan løses med feks dynamisk programmering isteden for rekursivt kan man spare en drøss med tid. Men det er ikke alltid like lett og finne ut av det om man ikke har gjort det noen ganger før.

- Det hender også ganske ofte (hvertfall for meg) att en jobber med problemer som er satt sammen i grafer (eller noen ganger trær), og da er det kjekt og hvite en del om algorithmene angående det temaet.

- Er også kjedelig om en har ett polynomsk/pspace(P - n**k) problem også løser man det i eksponensiel tid (x**n) isteden siden man ikke kjente igjen problemet som P. Er også kjekt og kunne klare og finne ut om problemet er NPC slik at man ikke bruker tid på å finne en effektiv algorithme i polynoms tid.

- osv...

 

 

Noe jeg skulle likt og visst litt tidligere er også at design patterns (+ andre, som sikkerhets og arkitektur patterns) også er veldig viktig.

[sinnaelgen]

Er det noen som har klart å lage et program som lister ut konfigurasjonen/oppsettet til logitech harmony fjernkontroller ?

[Dead_Rabbit]

Er selvsakt et stort pluss ok kunne språket ut og inn, men jeg mener nå det er viktigere og kunne algorithmer en å kunne en mengde forskjellige språk ut og inn. Hoved grunnen for å lære ett nytt språk burde være enten att man trenger det i jobb sammenheng, eller til eget prosjekt hvor det språket er desidert best til den aktuelle oppgaven (og man kan ingen andre som ligger like bak), eller at logikken bak det er såpass anderledes så man lærer en ny måte og tenke på når man lærer seg språket.

Som GeirGrusom har nevnt, er algoritmer noe man kan slå opp. Når det gjelder språk, så er det noe annet. Du kan slå opp i dokumentasjonen osv, men det er likevel en stor forskjell på å skrive et fungerende program i et språk og det å virkelig kunne språket. Det er viktig å vite styrker og svakheter og "does and don'ts" i forhold til språket. Dette mener jeg er kritisk når man designer et program.

 

Hvis du ønsker ett raskt program så er det ikke alltid nokk å bare slå opp. Du må også vite når du skal bruke hva(feks. med tanke på tid, plass osv.), og ofte må du også tilpasse deler av algorithmen til ditt problem(feks. heuristic).

-Det å velge en god heuristic for et heuristic søk er ikke så lett å bare slå opp (med mindre du har ett klassiskt problem). Med en dårlig heuristic så kan man risikere at søket tar mange ganger så lang tid, noe som er et stort problem om n er stor.

- Om man kan gjenkjenne om et problem kan løses med feks dynamisk programmering isteden for rekursivt kan man spare en drøss med tid. Men det er ikke alltid like lett og finne ut av det om man ikke har gjort det noen ganger før.

- Det hender også ganske ofte (hvertfall for meg) att en jobber med problemer som er satt sammen i grafer (eller noen ganger trær), og da er det kjekt og hvite en del om algorithmene angående det temaet.

- Er også kjedelig om en har ett polynomsk/pspace(P - n**k) problem også løser man det i eksponensiel tid (x**n) isteden siden man ikke kjente igjen problemet som P. Er også kjekt og kunne klare og finne ut om problemet er NPC slik at man ikke bruker tid på å finne en effektiv algorithme i polynoms tid.

Selvfølgelig forutsetter det jo at man har en generell kunnskap når det gjelder algoritmer hvis man skal kunne slå opp. Dette her er jo ting som man typisk vet. Det jeg tror GeirGrusom sikter til, er at det er unødvendig å gå rundt og huske en masse algoritmer for forskjellige ting. Algoritmer ifm. grafer er jo et typisk eksempel på algoritmer som i og for seg er unødvendig å gå rundt og huske på. Og som du sier, så er dynamisk programmering en treningssak, men DP kan jo heller ikke sies å være "en algoritme" som sådan. Det er mer en tankegang/mønster for å designe algoritmer.

[-kga-]

Selvfølgelig forutsetter det jo at man har en generell kunnskap når det gjelder algoritmer hvis man skal kunne slå opp. Dette her er jo ting som man typisk vet. Det jeg tror GeirGrusom sikter til, er at det er unødvendig å gå rundt og huske en masse algoritmer for forskjellige ting. Algoritmer ifm. grafer er jo et typisk eksempel på algoritmer som i og for seg er unødvendig å gå rundt og huske på. Og som du sier, så er dynamisk programmering en treningssak, men DP kan jo heller ikke sies å være "en algoritme" som sådan. Det er mer en tankegang/mønster for å designe algoritmer.

En god å dyp forståelse om så mange som mulig algorithmer og datastrukturer er etter min mening mye viktigere en å kunne ett språk så godt att du nesten aldri trenger å slå opp for ting du lurer på angående språket.

Ser jeg forklarte meg elendig i starten (noe som dessverre hender litt for ofte). Jeg mente ikke at man trenger å huske nøyaktig hvordan algorithmen fungerer uten å behøve og slå opp. Tanken var at der er viktig å ha en fortåelse av hvordan den fungerer, når den bruken, positive og negative sider osv. Også som det jeg nevnte om heuristic og DP så er det også nyttig og kunne designe algorithmer, og for å designe algorithmer så er det greit og ha en del kunnskap om forskjellige algorithmer og metoder som kan brukes/tilpasses.

 

Det er viktig å vite styrker og svakheter og "does and don'ts" i forhold til språket. Dette mener jeg er kritisk når man designer et program.

Forde fleste større språk så fintes det bøker som er spesialisert for folk som kommer fra ett språk og migrere over til ett annet. Ofte har de navn som, "Python for java utviklere", "Fra c++ til Java", osv... Slike bøker, om de er noe gode, tar normalt opp viktige forskjeller som en burde lære seg.

[GeirGrusom]

Ser jeg forklarte meg elendig i starten (noe som dessverre hender litt for ofte). Jeg mente ikke at man trenger å huske nøyaktig hvordan algorithmen fungerer uten å behøve og slå opp. Tanken var at der er viktig å ha en fortåelse av hvordan den fungerer, når den bruken, positive og negative sider osv. Også som det jeg nevnte om heuristic og DP så er det også nyttig og kunne designe algorithmer, og for å designe algorithmer så er det greit og ha en del kunnskap om forskjellige algorithmer og metoder som kan brukes/tilpasses.

 

Det er viktig å vite styrker og svakheter og "does and don'ts" i forhold til språket. Dette mener jeg er kritisk når man designer et program.

Forde fleste større språk så fintes det bøker som er spesialisert for folk som kommer fra ett språk og migrere over til ett annet. Ofte har de navn som, "Python for java utviklere", "Fra c++ til Java", osv... Slike bøker, om de er noe gode, tar normalt opp viktige forskjeller som en burde lære seg.

Akkurat samme kan du si om algoritmer og da. Det finnes egne bøker om parsing, om forskjellige lister, 3D grafikk, kollisjonsdeteksjon, hydrodynamikk, statikk osv.

 

Jeg vil påstå at algoritmer er vitenskap, mens selve programmering er kunst. Algoritmer kan kanskje hjelpe deg til å se hvor du skal bruke hva, men programmeringen(noen som vet om et bedre begrep?) er det som binder elementene sammen, og gjør deg istand til å kunne endre algoritmen til å passe dine behov. Dette er relativt tett knyttet til programmeringsspråket du bruker. Det er ikke alltid bare rent overfladiske forskjeller, det kan være helt andre ting, som funksjonelle språk som effektivt vil kreve at en nesten må starte på nytt, fordi tankegangen må være helt annerledes.

 

Men det er selvsagt ikke dumt å kunne algoritmer, men jeg vet ikke om flere=bedre nødvendigvis. Men mer til poenget, så synes ikke jeg algoritmer er det som er vanskelig med programmering, men å kunne umiddelbart se mulige løsninger på problemet. Noen kan deler kan være forhåndsdefinerte algoritmer, men andre deler må en finne ut av helt på egenhånd.

[Johan]

Men det er selvsagt ikke dumt å kunne algoritmer, men jeg vet ikke om flere=bedre nødvendigvis. Men mer til poenget, så synes ikke jeg algoritmer er det som er vanskelig med programmering, men å kunne umiddelbart se mulige løsninger på problemet. Noen kan deler kan være forhåndsdefinerte algoritmer, men andre deler må en finne ut av helt på egenhånd.

 

Men det er jo nettopp dette som er poenget!

 

La meg sitere Wirth: "Algorithms + Data Structures = Programs"

 

Hvis du ikke har greie på algoritmene så kan du ikke umiddelbart (eller mer realistisk etter litt utpønsking) se løsingen på problemene, med mindre vi snakker om trivialiteter. Har du greie på dem så kan man se, jo problem X er egentlig A* søk hvor grafen blir sånn og h(.) sånn, problem Y kan løses med dynamisk programmering hvor tabellen fylles sånn og sånn, man kan se at et problem kan beskrives av en endelig tilstandsmaskin, man kan se at et problem er NP-komplett man kan se at dette er et flytproblem eller matchingproblem osv. Det å faktisk putte ting inn i et programmeringsspråk når man først har en mental modell for hvordan beregningen skal foregå er det stort sett ikke et problem å få $HIPT_SPRÅK til å gjøre det for deg.

 

Poenget er å forstå og raskt oppdage at problemet man forsøker å løse lar seg utrykke i en eller annen _generell_ (forhåndsdefinert om du vil) algoritme og hvis man ikke kan dem (i det minste nogenlunde) hjelper det ikke å kunne slå opp heller, fordi man aner ikke hvor man skal begynne å lete. Og hvis man begynner med litt mer avanserte algoritmer hjelper det kanskje ikke å slå opp heller, med mindre man har lang erfaring eller god utdannelse.

 

Dette er det jeg mener er det viktigste. Programmeringsspråk kommer og går, men algoritmene består Det å klare å instansiere riktig generelle algoritme kan være forskjellen på om problemet i det hele tatt lar seg løse. Ikke det at det er også er viktig å kunne programmere fint og forståelig (noe som ofte er vanskelig), men hvis du allerede er godt utpå jordet så hjelper det ikke uansett hvor idiomatisk/flott man er.

 

Så kan man i neste rekke si at det er viktig å kunne forskjellige programmeringskonsepter, som objektorientering (gjerne i flere former, java smalltalk CLOS) funksjonell programmering, logisk programmering osv osv. Dette er på en måte også algoritmer, men de løser et annet problem, nemlig hvordan beskrive en algoritme i et kjørbart format.

[-kga-]

Algoritmer kan kanskje hjelpe deg til å se hvor du skal bruke hva, men programmeringen(noen som vet om et bedre begrep?) er det som binder elementene sammen, og gjør deg istand til å kunne endre algoritmen til å passe dine behov. Dette er relativt tett knyttet til programmeringsspråket du bruker. Det er ikke alltid bare rent overfladiske forskjeller, det kan være helt andre ting, som funksjonelle språk som effektivt vil kreve at en nesten må starte på nytt, fordi tankegangen må være helt annerledes.

Det hender ganske ofte at man må tilpasse algoritmer på pseudokode nivå også. For å tilpasse for funksjonelle språk spå kan mye av det også gjøres på pseudokode nivå slik at det passer for de fleste funksjonelle språk.

 

Men som du nevner så skjer jo selvsakt den siste tilpassingen på programmeringsspråk nivået. Og viss man ønsker topp ytelse så er jo dette nivået også viktig, enda en elendig algoritme antagelig kan ødelegge en del mer på ytelsen en feks det å kode som en java programmerer i python.

 

Akkurat samme kan du si om algoritmer og da. Det finnes egne bøker om parsing, om forskjellige lister, 3D grafikk, kollisjonsdeteksjon, hydrodynamikk, statikk osv.

...

Men det er selvsagt ikke dumt å kunne algoritmer, men jeg vet ikke om flere=bedre nødvendigvis.

Det er antagelig ikke så mye og tjene på og kunne en mengde algoritmer innen mange forskjellige spesifikke emner som parsing, 3d grafikk og statistikk om en ikke skal jobbe med det. Det er like unødvendig som å lære seg ett nytt språk som er nesten helt likt et annet man kan kun for å lære seg ett språk ekstra.

 

Derimot om man har en god oversikt over en del forskjellige metoder innen søk, sortering, grafer, trær, optimalisering, approximasjon, design metoder og andre metoder og algoritmer som lettere kan bli brukt innen en rekke forskjellige områder så vil det nokk være til stor hjelp. Det blir vel til en viss grad sammenlignes med at når man vil lære seg ett nytt språk kun for å lære ett til (Ikke for at man trenger det til noe spesifikt) så velger man heller ett språk som er veldig anderledes en de man allerede kan (men har likheter til andre språk), slik at man kan bruke den kunnskapen for å lettere lære seg ett nytt lignende språk om det en gang skulle bli nødvendig. Feks. Om man ikke kan noen funksjonelle språk, så velger man ett slikt.

[GeirGrusom]

Min erfaring ifra høyskolen, er at elevene der har enklere å forstå algoritmer enn de har med å forstå programmering. I løpet av de tre årene nå, så er de færreste istand til å skrive programmer på egenhånd, enda de kan linked list, queue, stack, generiske algoritmer, radix sort, quick sort, etc. etc. etc. som de har hatt som egne fag.

 

Likevel, så trøbler de aller fleste med helt grunnleggende ting, som for eller while? struct eller class? interface eller abstract? hvilken datatype?

Selv om de kan alle disse algoritmene godt, og har hatt obligatoriske innleveringer i dem, så trengte samtlige hjelp i grafisk databehandling, når en faktisk skulle sette sammen et program helt på egenhånd. Grunnen sånn jeg ser det, er at det blir fokusert alt for mye på algoritmer, og alt for lite på generell programmering. En blir ikke flink til å programmere av å kunne algoritmer.

 

Greit algoritmer blir stående, men det er ikke forhåndsdefinerte algoritmer du kommer til å jobbe med hver dag heller. Du kommer til å jobbe med ett eller flere programmeringsspråk, der løsningen ikke med en gang er en samling algoritmer du har i hodet. Og ja, alle algoritmer kan slåes opp, eller en kan spørre på et vennlig forum slik som her om hvilken algoritme som passer til oppgaven, dersom det engang er nødvendig.

Etter min erfaring består det meste dog av å finne egne løsninger på problemer, og dytte inn algoritmer der problemet ikke lenger er trivielle, som er relativt få (selvsagt avhengig av hva du jobber med) En kan ikke forvente at alle problemer bare er klipp-og-lim av algoritmer, for det er overhode ikke realistisk.

 

Ikke at det er teit å kunne algoritmer, men jeg synes bare ikke at det er den vanskelige delen av programmering.