ProgrammeringsBaren! Småprat, om det du elsker!

[Goophy]

Tja, det er ikke så ille egentlig, bare noe begrenset.

Problemet er at det ikke finnes noen erstatninger som kan konkurrere på oppetid og ytelse på platformen som brukes (HP Nonstop). Bytte platform er uaktuelt med tanke på hvor kritisk oppetid er.

[steingrim]

Oj 90% COBOL, jeg må bare spørre om hva du bruker det til?

Kortbetalingssystemer.

Hm. Sitter du samme sted som meg mon tro?

[Goophy]

Hm. Sitter du samme sted som meg mon tro?

Gjør nok ikke det, jobber i det andre selskapet i Norge som driver på med sånt.

Vi har bensinstasjonene som kunder, dere har resten. Hehe.

[zotbar1234]

Hvis jeg nevner at jeg skriver 90% i COBOL på jobben burde det gi meg nok kredibilitet.

 

Svar på Project Euler #218 ønskes fortsatt desperat!

 

Jeg synes kombinasjonen av projecteuler og cobol gir deg kredibilitet. Spesielt hvis du *løste* oppgavene 1-217 *i* cobol (jeg slapp dessverre opp for enkle problemer halvveis og fant det vanskelig å motivere meg selv å løse flere deg. Må få lurt steingrim til å hjelpe meg).

[Goophy]

Jeg synes kombinasjonen av projecteuler og cobol gir deg kredibilitet. Spesielt hvis du *løste* oppgavene 1-217 *i* cobol

Hehe, så gal er jeg nok ikke. Tror ikke det hadde gått an innen rimelig tid i COBOL uansett.

Brukte Lisp, Haskell og Matlab/Mathematica stort sett.

Endret 20. april 2009 av Goophy

[....]

Hvorfor er emacs lisp så spesielt?

Åpen kildekode og transparent eksekvering.

 

«Åpenhet» i en bredere betydning. Som du vet er det spesielle med Emacs at hele editoren er skrevet i Emacs Lisp, slik at koden for enhver funksjon kan slås opp med et par tastetrykk. Der andre programmer avgrenser slik transparens til et eget rammeverk for innpluggingsmoduler, trygt isolert fra alle forretningshemmelighetene i den lukkede hovedkoden, gir Emacs deg tilgang til hele maskineriet uten forbehold – mens du har Emacs oppe.

 

Hvis jeg lurer på hva en av piltastene gjør, for eksempel, trykker jeg C-h k <up> og får opp dokumentasjonen for previous-line, samt definisjonen i Emacs Lisp. Ethvert element i koden er tilsvarende dokumentert, og funksjonen kan modifiseres med øyeblikkelig virkning – i mitt oppsett rydder den bort mellomrom på slutten av linjen mens jeg navigerer rundt i bufferen. Emacs lar meg modifisere Emacs mens Emacs kjører.

 

Noen sa at tilgang til kildekoden gir brukerne større frihet, og mang en bruker har lastet ned en drøss med kryptiske .c-filer uten å bli det spøtt klokere. Emacs setter koden i kontekst ved å eksekvere den. Det er fryktelig instruktivt å ikke bare kunne lese om, men også se hva en bestemt funksjon gjør, umiddelbart – uansett dens plassering i maskineriet. («Example is the school of mankind, and they will learn at no other.»)

 

Vi trenger flere og bedre verktøy for å lære av hverandres innovasjoner, som er hva åpen kildekode egentlig handler om. Åpen kildekode er mer enn å bare slenge på en lisens – det innebærer også praktisk tilrettelegging for bruk av koden. Emacs’ måte er uforbeholden transparens. Jeg skulle ønske jeg kunne få dét også i Visual Studio og Vim.

Endret 8. februar 2012 av ....

[GeirGrusom]

Hmm det er jo ganske kult

[DeadManWalking]

Oki, Java relatert spørsmål. Jeg lager et binærtre og noe er feil et sted. Så et lite spørsmål angående objekter.

En node er definert med en klasse. Hver node har to subnoder, den venstre og en høyre. Når jeg skal sitte inn noe så blir det ikke registret. La oss si at treet har kun et element. Et tall, nummer 5. Hvis sitter inn 4 så skal det havne i root.LChild. Det jeg putter inn i root.LChild er altså et objekt av Node klassen min som har en variabel ved navn data hvor 4 tallet er lagret. Koden hvor dette skjer ser slik ut:

 

digginDeeper=tmpNode//DigginDeeper er root.getLChild parset som en parameter til en rekursiv funksjon

root.getLChild == null //Blir true

 

digginDeeper er root.LChild og tmpNode er 4 tallet.

Dette er en rekursiv funksjon så root.lChild er en parameter, hvis jeg tester dette rett etterpå er den jo null?

Altså, root.getLChild == null. Wtf, jeg har jo parset den. Greit, den jo faktisk null når den blir parset fordi den noden ikke inneholder en node enda. Det er noe med pointere og referanseverdier jeg ikke har forstått.

 

Mye rot og mye mas, en is på den som hjelper.

[x871kx6167ss7]

Hmm, jeg har ihvertfall problemer med å forstå hva som skjer i den teksten din.

[DeadManWalking]

Kort sagt da, kan denne biten med C++ direkte overføres til Java:

void InsertNode(Node* &treeNode, Node *newNode)
{
 if (treeNode == NULL)
   treeNode = newNode;
 else if (newNode->key < treeNode->key)
   InsertNode(treeNode->left, newNode);
 else
   InsertNode(treeNode->right, newNode);
}

[x871kx6167ss7]

Nå er jeg ikke noen ekspert på C++, men «Node* &treeNode» betyr vel at det er pass by refrence? I så fall går det ikke å overføre direkte, nei. Java har bare pass by value(du gir referanser, som verdi).

[DeadManWalking]

Ja, den linjen er en peker til et minneområdet som inneholder Node. Hmm. Da blir det verre. Uff.

 

Da forsetter jeg i morgen, for da må jeg implementere det med en løkke eller noe.

Endret 21. april 2009 av data_jepp

[x871kx6167ss7]

Neida, det er bare en liten endring som må til. Eneste grunnen til at det ikke fungerer er fordi du «forsinker» tilordningen en iterasjon for mye. Så i stede for å kalle «blindt» på InsertNode, så kan du sjekke de fire mulighetene, og ved to av dem så kaller du ikke InsertNode, men setter variablen.

 

Den skal til høyre && høyre == null

Den skal til høyre && hoyre != null

Den skal til venstre && venstre == null

Den skal til venstre && venstre != null.

[DeadManWalking]

Greit, jeg jobber litt videre med treet mitt. Sakset følgende fra Wikipedia:

* Deleting a leaf: Deleting a node with no children is easy, as we can simply remove it from the tree.

* Deleting a node with one child: Delete it and replace it with its child.

* Deleting a node with two children: Suppose the node to be deleted is called N. We replace the value of N with either its in-order successor (the left-most child of the right subtree) or the in-order predecessor (the right-most child of the left subtree).

 

Greit nok, jeg forstår de to øverste. Den nederste sliter jeg litt med. La oss si at N er root i det treet jeg har tegnet under. Da er det enten 15 eller 25 som skal erstatte root noden, også videre nedover må jeg også oppdaterer at 15 eller 25 flyttes opp til topps? Hvis treet er stort blir dette stress jo. Er det sånn det skal gjøres?

Her blir det jo bare å flytte opp venstre subtre til 15 eller 25, da tenker jeg rett? Lurer bare litt på hvordan jeg skal implementere dette sånn at alle ledd blir "shufflet" opp riktig hvis man sletter rooten i et stoooort tre.

 

[x871kx6167ss7]

Hai hå! En ting som plager meg litt her. I video-forelesningene til SICP, og de driver å snakker om register-maskiner.

 

Først så har de en tenkt 7-register-maskin, og skriver et program som kan evaluere lisp-kode. Denne evaluatoren er jo da skrevet i et assembly-liknenede språk. Så sier de etterpå at dersom maskinen bare skal kjøre kompilert kode, så trenger den bare 5 register. Enten så missforstår jeg noe, eller så greier jeg bare ikke å se det.

 

Dersom man skriver en evaluator og kompilerer den for en 5-regsiter-maskin, så vil jo denne gjøre akkurat det samme som 7-register-maskinen. Og instruksjon-settet er jo det samme, bare det at den har to mindre register. Hvorfor i granskauen kan man ikke da «skrive om» koden som ble brukt i 7-register-maskinen på samme måte som kompilatoren gjør?

Endret 26. april 2009 av Blackslash

[....]

Leste gjennom noen gamle Usenet-diskusjoner fra 2002 og kom over følgende utblåsning:

 

Screwed-up initial design together with endless reinvention is why IT is such a disaster. C not good enough for you? Let’s have C++, or this other version of C++, or this one. No, let’s reimplement in Java. Or C#. Or Python. Perl. Ruby. SGML no good? […] Just reinvent everything once again, use XML (it must work, it’s so big and complicated by now – how can anything that big not work), and we’ll all get rich this time. Right. Sure. I’ll just do something else, if you don’t mind.

Hvor mye lenger har vi kommet siden den gang? Det er mye revolusjon, men lite evolusjon. Spørsmålet er: Hvilke av dagens plattformer vil bestå inn i fremtiden, og er verdt å investere i?

Endret 8. februar 2012 av ....

[DeadManWalking]

Det er vel prisen å betale når man jobber med noe som har et evig forbedringspotensial. Plager ikke meg, gleder meg til mange fine år i bransjen.

[hishadow]

Spørsmålet er: Hvilke av dagens plattformer vil bestå inn i fremtiden, og er verdt å investere i?

De du kan tjene penger på.

[Giddion]

Spørsmålet er: Hvilke av dagens plattformer vil bestå inn i fremtiden, og er verdt å investere i?

 

C/C++ kan jeg ikke se for meg dø ut .... vel de fleste vil sikkert overleve... folk skriver jo fortsatt kode i COBOL og det stammer fra 1959.

 

Jeg syntes ikke at IT er en katastrofe og syntes det er bra at nye bedre ting kommer.

 

tenke tenke... assembly vil helt sikkert overleve... sats på det du.

[DeadManWalking]

Samboeren min sin datamaskin kom med Vista, nå vil jeg ha Xp på den. Linux er hun ikke helt moden for enda. Vi studerer begge ved UiB, jeg studerer informatikk og jeg vet at vi (UiB) er tilknyttet den ordningen med Microsoft som gir oss tilgang på mye gratis programvare fra Microsoft. Inkluderer det også Xp?