Svenska ElektronikForumet

Detta "slöseriet" med resurser som många pratar om leder oftast till kortare och mer lättläst kod
med mindre buggar än snabbare kod. Att man väljer att få buggfri kod som är enkel att underhålla
(= billigare) över att få snabb är inte så konstigt då en använda ändå inte märker någon skillnad
så länge man håller sig till 16ms per frame vilket ofta är extremt långt.

Jag kan ärligt talat inte så mycket om programmering (heller ) för jag har bara hjälpligt programmerat i C och speciellt iom mitt Aurduino UNO projekt.

Men för mig låter det som om du pratar lite i nattmössan

Kodeffektiv (lågnivå)programmering och därmed minimal mängd med maskinkod kan aldrig bli buggigare än "lättläst" högnivåprogrammering.

Detta för att vid högnivå-fallet har du två bovar till onödig mängd maskinkod. Bov nummer ett har att göra med hur väl själva kompilatorn är skriven och bov nummer två har att göra med hur lättläst koden görs (vilket dock onekligen är en fördel).

Och ju mer maskinkod du skapar (för samma sak) desto större är sannolikheten för buggar, eller hur?

Dessutom går det långsammare.

Detta är f.ö anledningen till att jag aldrig "uppgraderar" min hyfsat stabila vintage-Firefox (9.0.1) för ingen ska inbilla sig/mig att mängden maskinkod blir mindre med tiden!

Samtidigt gör i grund och botten senaste Firefox precis samma sak som min gamla! Den är bara större och därmed buggigare

MVH/Roger
PS
Assembler regerar

Det är inte speciellt många som håller med dig.

Om man har en bugg i koden som t.ex gör att man missar
skottår vid daturmberäkningar, så har det ingen som helst
betydelse vilket språk den buggen är skriven i, så klart.

Och sannolikheten för att det ska bli buggfritt är större om
man använder färdiga datumrutiner i något bibliotek än om
man själv skriver samma rutiner från scratch.

Eller så kan man se det som så att skriver man allt i assembler är det JÄTTELÄTT att du missar något som gör att programmet går åt skogen. Ta tex C++ som förenklar avsevärt. Med en kompilator som g++ får man heller inte mycket overhead eftersom den är så pass optimerad av väldigt många (händer även att den "skiver om" kod för att optimera).

"skriver man allt i assembler är det JÄTTELÄTT att du missar något som gör att programmet går åt skogen"
Det kan gå åt skogen i andra språk också..... Jättelätt

Swech

Klart det kan. Men är ännuvärre med assembler (till större projekt) och jag tvekar på att de flesta skriver bättre assembler än vad kompilatorn genererar (till c/c++).

Det är definitivt så, men problematiken är ju på ett annat plan.
Såg i helgen ett exempel i en bok som lär ut Java.
Programmet skulle räkna ut primtal vilket det gjorde men de
hade missat att man inte behöver testa jämna tal, primtal är alltid udda.
Så programmet räknade alltså 50% i onödan.
Oavsett kompilator eller språk så är det ett exempel på att man inte längre behöver
optimera VAD som skall göras, det går tillräckligt fort ändå för att man skall lägga
tid på att tänka efter.....

Samma gäller även större och större program, De kan göra saker helt i onödan eftersom de per definition
är svåra att överskåda.

Swech

rogerk8 skrev:Jag kan ärligt talat inte så mycket om programmering (heller ) för jag har bara hjälpligt programmerat i C och speciellt iom mitt Aurduino UNO projekt.

Men för mig låter det som om du pratar lite i nattmössan

Kodeffektiv (lågnivå)programmering och därmed minimal mängd med maskinkod kan aldrig bli buggigare än "lättläst" högnivåprogrammering.

Detta för att vid högnivå-fallet har du två bovar till onödig mängd maskinkod. Bov nummer ett har att göra med hur väl själva kompilatorn är skriven och bov nummer två har att göra med hur lättläst koden görs (vilket dock onekligen är en fördel).

Och ju mer maskinkod du skapar (för samma sak) desto större är sannolikheten för buggar, eller hur?

Dessutom går det långsammare.

Detta är f.ö anledningen till att jag aldrig "uppgraderar" min hyfsat stabila vintage-Firefox (9.0.1) för ingen ska inbilla sig/mig att mängden maskinkod blir mindre med tiden!

Samtidigt gör i grund och botten senaste Firefox precis samma sak som min gamla! Den är bara större och därmed buggigare

MVH/Roger
PS
Assembler regerar

Så om jag får mycket mindre kod som är enklare att läsa på grund utav att jag använder ett
ramverk från t.ex. Google som är automatiskt testat och används av tusentals andra så tror du
att jag får mer buggar?

Buggar kommer i all programvara, men kan försvinna med fler tester. Eftersom många andra har
testat det ramverket/kompilatorn/biblioteket jag använder så har det med högsta sannolikhet många
färre buggar än den kod jag skrivit som bara är testad av ett fåtal personer.

Det beror också på hur nogrann skaparen och underhållaren av programvaran är. Oracle verkar inte vara att att lita på t.ex och knappast Microsoft heller. Varvid drivkrafter spelar stor roll också. Dvs $$ eller att man gillar programmering.

I övrigt så brukar programvara som används av många och under längre tid fungera väldigt bra.

Med google mm så får man dock också oftast deras datagrävning insmygd på köpet.

Swech skrev:Det är definitivt så, men problematiken är ju på ett annat plan.
Såg i helgen ett exempel i en bok som lär ut Java.
Programmet skulle räkna ut primtal vilket det gjorde men de
hade missat att man inte behöver testa jämna tal, primtal är alltid udda.
Så programmet räknade alltså 50% i onödan.
Oavsett kompilator eller språk så är det ett exempel på att man inte längre behöver
optimera VAD som skall göras, det går tillräckligt fort ändå för att man skall lägga
tid på att tänka efter.....

Samma gäller även större och större program, De kan göra saker helt i onödan eftersom de per definition
är svåra att överskåda.

Swech

Klockrent

Det är indirekt mycket av det här jag så tafatt (och tyket) försöker förklara.

Jag tror det finns mängder med sådana här fall i datavärlden!

Där CPU'erna bara tuggar kod helt i onödan!

MVH/Roger
PS
Jag la till nåt om "klåfingriga programmerare" i mitt förra inlägg också men tog bort det för jag tyckte det grötade ner inlägget. Men ovanstående vittnar om att jag borde haft med det för ingen kompilator i världen hjälper mot den typen av klåfingrighet

>Där CPU'erna bara tuggar kod helt i onödan!
Visst är det så. Men eftersom folk vill ha buggfria program som är gratis och helst igår
så blir det så.

Se gärna denna om du är intresserad an ämnet

Men det samma gäller andra brancher. Om folk bara ville betala så skulle vi få mycket
säkrare vägar om vi skrotade alla bilar äldre än tre år.

>Oracle verkar inte vara att att lita på t.ex och knappast Microsoft heller. Varvid drivkrafter spelar stor roll också. Dvs $$ eller att man gillar programmering.
För att tjäna mycket $$ brukar man oftast behöva väldigt buggfri kod.
Även Microsoft eller Oracle program är mer buggfria än nyskriva program oavsett utvecklare
(enda sättet de skulle vara bättre initialt är om de var utvecklade på en högra nivå med
en vältestad grund).

>Med google mm så får man dock också oftast deras datagrävning insmygd på köpet.
Visa mig gärna datagrävning i Angular, Polymer eller Dart?

Generellt sett så lönar sig assemblerprogrammering (inte maskinkod) endast för lågnivåsystem (boot, paging, CPU lägesändring real->prot osv) eller för I/O med benhårda krav på antalet klockcykler som får gå åt. I stort sett så gick man över till C (ev Forth) eller andra effektiva högnivåspråk så fort det fanns möjlighet till detta.

Detta då C får ses som lägsta nivå där arbetsinsatsen är försvarbar för resultatet. Sedan finns det andra fall där skriptspråk eller funktionella språk är mer lämpade. Dock brukar de vara skriva i C.. Tillbaks till punkt 1. Det är också lättare att hålla koll på vad man gör när man kan slänga upp så många variabler man behöver utan hänsyn till hur många register processorn har när man skriver en matteformel som dataprogram. Det minskar mängden buggar helt enkelt.

Är det något som tuggar onödiga klockcykler så är det väl annars Microsofts produkter och Nortons. Med tanke på att det sker i persondatorer så multipliceras detta rätt kraftigt och kräver säkert någon extra kärnreaktor.

Något som persondatorer kunde bli bättre på är att få ordning på ACPI skripten så att "sleepmode" mm fungerar korrekt. ADSL modem kunde ha något lågkapacitetsläge osv.

@Pajn, För att tjäna $$ behöver man vendor-lock-in och bra marknadsföring. MS/Oracle (java) kan inte ses som något under av buggfrihet. Eller möjllighet att få till detta åtgärdat. Ang Google så tänker jag mest på deras javascript produkter som många webinvecklare ofta anropar direkt från google.com vilket öppnar många mörka möjligheter.

blueint skrev: Är det något som tuggar onödiga klockcykler så är det väl annars Microsofts produkter och Nortons. Med tanke på att det sker i persondatorer så multipliceras detta rätt kraftigt och kräver säkert någon extra kärnreaktor.

Underbart roligt uttryckt!

Apropå Norton så hade jag faktiskt det ett tag men när det gick ut och dels kostade 700:- dels tjatade hela tiden beslöt jag mig för att avinstallera det.

Gissa vad som hände?

Windows XP kom plötsligt igång på en halv minut istället för typ fyra

MVH/Roger

blueint skrev: Något som persondatorer kunde bli bättre på är att få ordning på ACPI skripten så att "sleepmode" mm fungerar korrekt. ADSL modem kunde ha något lågkapacitetsläge osv.

Kolla på haswell, drar väldigt lite ström i sleepmode och kan även dra väldigt lite när den
fortfarande är vaken.

blueint skrev: @Pajn, För att tjäna $$ behöver man vendor-lock-in och bra marknadsföring.

Inte alls, kolla på Red Hat.

Sammanfattning:

Vi har alltså dessa sex bovar till kodineffektiva program och därmed långsammare 32-bit SC-maskiner än nödvändigt:

1) Högnivåspråk
2) Lättläst kod
3) Mindre bra kompilatorer
4) Klåfingriga programmerare (där varken typ av språk eller kompilatorkvalitet hjälper)
5) Onödiga finesser
6) Klart igår...

MVH/Roger