ProgrammeringsBaren! Småprat, om det du elsker!

[tingo]

Feilmeldinger var morsommere i gamle dager: http://www.ralentz.com/old/mac/humor/mpw-c-errors.html

[GeirGrusom]

Too many errors on one line (make fewer)

Den var fin

[Matsemann]

Kan hende en del har sett den før, men her er artig programmeringsslang. LINK

Liker spesielt

Pokémon Exception Handling

When you catch all the exceptions and then you try somehow to analyze them.

 

og

Smug Report

A bug report submitted by a user who thinks he knows a lot more about the system’s design than he really does. Filled with irrelevant technical details and one or more suggestions (always wrong) about what he thinks is causing the problem and how we should fix it.

[tomsi42]

Kan hende en del har sett den før, men her er artig programmeringsslang. LINK

Herlig - likte definisjonen på Refactoring

[tingo]

Jepp, mye bra der - takker!

[GeirGrusom]

Jeg har sittet og tenkt på en ting i det siste. Jeg har brukt mye tid på å skrive parser og compiler for tiden, og sitter og funderer på om det ikke går an å bare hoppe over den klassiske parsingen.

Dette forutsetter derimot at en parser blir erstattet av et mer generelt verktøy: et uttrykstre-bygger. Dette blir et slags IDE som kan ligne mye på de vanlige teksteditorene, men hva du kan skrive hvor vil bli kontekstavhengig.

Grunnen er at når du skriver, så skriver du ikke et flatt tekstdokument, men du oppretter en trestruktur som blir skrevet ut som en binærfil. Overfladisk er forskjellen ganske liten fra kilde-kode tekst, men jeg kan forestille meg en del fordeler:

- Syntaks-feil blir umulig å skrive, ettersom det ikke vil være mulig å danne et syntakstre som ikke gir mening på en eller annen måte

- White space vil aldri spille en rolle, og hvordan dokumentet vil se ut for brukeren er utelukkende definert av brukeren, og vil ikke bli lagret i dokumentet.

- Ingen tung parsing kreves utover å lese binærdokumentet.

- Kan gjøre diff-ing mer intelligent; flytting av komponenter vil ikke ha noen ting å si i en diff

 

I et nøtteskall er ihvertfall tanken å flytte lexing og parsing vekk som en oppgave for compileren og gjøre det til en oppgave for selve utviklingsverktøyet.

 

Foreløpig en lite gjennomtenkt sak, men tenkte kanskje det var noe som var verdt å diskutere.

[torbjørn marø]

Jeg har sittet og tenkt på en ting i det siste.

Jeg antar at du ikke har sett Scratch - et programmeringsspråk fra MIT laget for undervisning - ettersom det du sier er en ganske presis besrkivelse av dette språket / utviklingsmiljøet.

 

På et mere generelt grunnlag snakker du om grafiske programmeringsspråk. Det finnes vel etterhvert flere såkalte language workbenches som kan brukes til å lage grafiske DSL'er. Selv foretrekker jeg tekst, men det er mange som har tro på bruken av slike ting.

Endret 29. april 2012 av torbjørn marø

[GeirGrusom]

Jeg har sittet og tenkt på en ting i det siste.

Jeg antar at du ikke har sett Scratch - et programmeringsspråk fra MIT laget for undervisning - ettersom det du sier er en ganske presis besrkivelse av dette språket / utviklingsmiljøet.

 

På et mere generelt grunnlag snakker du om grafiske programmeringsspråk. Det finnes vel etterhvert flere såkalte language workbenches som kan brukes til å lage grafiske DSL'er. Selv foretrekker jeg tekst, men det er mange som har tro på bruken av slike ting.

tanken er vel noe av det samme, og jeg er godt kjent med slike ting. Det finnes mange programmeringsspråk som gjør dette. Tanken var derimot rettet mer direkte mot de generelle språkene. Når du sitter med et tomt dokument er det bare helt spesifikke ting en kan skrive i en gitt kontekst uten å bryte syntaktiske regler. Hvorfor engang tillate at brukeren skriver kode som ikke vil fungere? Hvis også ide-et tar seg av parsing av koden som skrives real-time for å danne et abstrakt syntakstre.

 

Skal se om jeg får litt tid på toget til å lage en demo av hva jeg forestiller meg. Det vil likne på vanlig programmering helt overfladisk, men vil sette en del begrensninger for hva en kan skrive.

Endret 30. april 2012 av GeirGrusom

[x871kx6167ss7]

Det du beskriver minner meg vel sånn sett om «structural editing» http://en.wikipedia....uctural_editing . Altså at editoren har full forståelse av komponentene og strukturen til språket, og kan passe på at teksten er velformet. Grensesnittet til editoren, og den interne representasjonen av koden, trenger jo da ikke nødvendig vis å være fri-tekst.

 

Dersom man skriver lisp i en strukturert editor (noe jeg ikke har gjort), så skal det vel godt gjøres å ha programmet i en tilstand hvor det ikke er syntaktisk velformet.

 

Har lest om en interaktiv bevisassistent som også var slikt.

 

Se f.eks. http://stackoverflow...editor-for-lisp

 

Samtidig så har du vel kanskje i tankene et språk med mer restriktivt typesystem enn lisp?

 

http://bannister.us/weblog/2005/01/19/structure-editors-ides-and-another-lisp-flashback/

Endret 3. mai 2012 av peterbb

[GeirGrusom]

At nemlig. Akkurat det jeg tenkte på. Språket i seg selv er egentlig uvesentlig. Det kan gjøres for ethvert språk.

[hakonvl]

Har tenkt å se litt på grafikkprogrammering med OpenGL, og lurer på om noen her som er drevne på 3d-programmering har noen synspunkter på dette med bøker. Har sett litt på Learning Modern 3D Graphics Programming, noen som har noen formeninger om dette? Har lest noen sider ut i boka, og det ser jo ut som boka er greit. På en annen side så står det at dette er en bok om grafikkprogrammering, ikke OpenGL.

Et annet alternativ er OpenGL Programming Guide: The Official Guide to Learning OpenGL (Som også har en "oppfølger" om shader language. Eventuelt OpenGL superbible, som er en smule utdattert mtp OpenGL 4.1. Andre forslag mottas med takk.

Bokkjøp er forøvrig ikke noe hindring, men om jeg bare kan skrive ut Learning Modern 3D Graphics Programming så blir det jo litt mindre ventetid, men om andre bøker går mer i dybden og fokuserer på viktigere ting, så er det mer interessant for min del.

 

Håper det er greit at jeg tar det her, og ikke i en annen tråd. Sitter forøvrig og googler litt mer om hva andre mener om bøkene nå, men fint med litt feedback her og

 

Edit: Fint om boka tar utgangspunkt i C++ eller C. FInt om koden kjører fint på Linux, men kan til nøds boote Windows.

Endret 17. juni 2012 av hakonvl

[mushin]

Hvis jeg kan endel C++ og jeg kjøper en bok hvor eksempler er skrevet i C, vil da syntaxen være relativt grei å fange opp? Vil helst bruke mest tid på å forstå det boka vil formidle, og ikke bli låst i masse C detaljer.

[tomsi42]

Hvis jeg kan endel C++ og jeg kjøper en bok hvor eksempler er skrevet i C, vil da syntaxen være relativt grei å fange opp? Vil helst bruke mest tid på å forstå det boka vil formidle, og ikke bli låst i masse C detaljer.

Det skal i utgangspunktet gå greit ettersom (litt forenklet) så er C noenlunde det samme som C++ uten objekter. I praksis betyr det at strenghåndteringen blir mer knotete, og algoritmer vil bruke pekere og strukturer istedet for objekter (og pekere),

 

Hva slags bøker er det snakk om?

[mushin]

Introduction to Computer Graphics av Foley, ... og Philips

http://www.amazon.com/Introduction-Computer-Graphics-James-Foley/dp/0201609215

 

Tar gjerne imot tips til andre bøker i samme sjanger. (Helst med endel dybde)

Endret 6. juli 2012 av mushin

[tomsi42]

Jeg tenkte meg nesten at det var noe i grafikk-sjangeren.

 

Jeg vil tro at det å bruke C++ i forhold til boka vil gå greit. Regner med at boken fokuserer på algoritmer og bilioteker som kan brukes både fra C og C++.

 

Anbefalinger om andre bøker har jeg ikke da dette er et fremmed felt for meg.

[mushin]

Mange takk tomsi, du har nok rett. Er ikke krise å slå opp visse ting i en C referanse bok heller.

[epsil]

Har tenkt å se litt på grafikkprogrammering med OpenGL, og lurer på om noen her som er drevne på 3d-programmering har noen synspunkter på dette med bøker.

 

Om disse bøkene har jeg hørt gode ting:

• Real-Time Rendering
  
• Game Engine Architecture
  

Jeg hadde egentlig håpet på at den drevne GeirGrusom ville veie inn med et svar på spørsmålet ditt – han har jo skrevet et spillrammeverk i C# og greier. (Wink wink, nudge nudge.)

[GeirGrusom]

Jeg har dessverre ingen bokreferanser å komme med. Spillprogrammering skiller seg ikke nevneverdig fra annen programmering. Stort sett er det som med alt annet; google er din venn. Det er noen algoritmer dog som er lurt å bite seg fast i: quad-tree og octree. Jeg gjetter at du vil få bruk for det. For selve 3D grafikken kan det være lurt å forstå litt lineær algebra, mer speaifikt vektorer, matriser og kvaternioner. Det kan være litt vanskelig å finne mattebiblioteker som ikke irriterer deg, så kanskje det kan være en idé å skrive dette selv. Vektorer og kvaternioner er enkle å skrive, men matriser er litt vrient fordi det blir veldig mye kode. For opengl gjelder egentlig bare referansen. Det vanskeligste med opengl er å få det til å virke i utgangspunktet. Noen GUI rammeverk kommer med innebygget GL støtte, men denne ser ut til ofte å være mangelfull.

 

edit: det er svært mye tutorials som bruker gamle OpenGL 1.1 og 2.x API-ene. Det er en stor fordel om du minst bruker OpenGL 3.0 (Sett på forward compatible core flaggene på kontekstet), men OpneGL 4.2 inneholder noen ting som er vrient å klare seg uten, eksempelvis at man kan binde flere fragment buffer til samme shader (glBindFragDataLocation) er ganske vesentlig dersom man vil bruke deferred rendering, pluss at tesselation shaders er blitt promotert til ARB.

Endret 10. juli 2012 av GeirGrusom

[Gjest Slettet+9871234]

Noen som har lest disse

 

Brackets: a Revolutionary Code Editor for the Web

 

som noen av kommentatorene ikke mener er så revolusjonerende.

 

Merk også denne kommentaren:

 

I see this project integrated into major projects such as wordpress, drupal in the future, since its offer better way to edit static content

 

JavaScript Closures Demystified

Endret 10. juli 2012 av Slettet+9871234

[GeirGrusom]

Quick reference på den måten hadde vært ganske kjekt. Nå bruker jeg CTRL+F12, men jeg pleier ofte å spore av når jeg gjør endrnger i den andre fila, og må søke meg tilbake igjen med CTRL+SHIFT+N.

edit: det er i Visual Studio med ReSharper.

Endret 10. juli 2012 av GeirGrusom