Programmering i andras ögon?

Om historien ska vara måttstock så kommer koden jag tog statistik från passera tiotusentals utvecklare under sin livslängd, de flesta kommer endast använda den men rätt många kommer behöva sköta underhåll. Kommenterar kring varför man gör något är helt ovärderligt 5-10 kanske 20 år senare, de som ursprungligen gjorde koden lär inte vara kvar och även om de är det så lär de knappast komma ihåg detaljer kring varför man gjorde på ett visst sätt om det inte är totalt uppenbart, vilket inte är fallet t.ex. när man implementerar en standard eller beror på ett visst beteende av underliggande lager (som kan ändra i framtiden och då är det väldigt värdefullt att hitta en förklaring till varför).

Syftet var väl
"Kan vi inte lägga ut några rader kod, och se vad folk tror att de står för?"
Tror det redan är rätt uppenbart att för folk som inte programmerar är allt utom möjligen de triviala fallen totalt hopplösa att reda ut.

Erlang-koden räknar antalet element av med ett visst värde och gör en form av histogram

[a,b,a,c,b,b] -> [a:2 b:3 c:1]

D.v.s. det fanns 2 "a", 3 "b" och 1 "c"

Bara för att man anser att luft är viktigare än vatten för att överleva så betyder inte det att vatten är värdelöst.

Dokumentation, test och kommentarer fyller olika funktioner och kan (och bör) alla existera samtidigt. Dokumentationen (som initialt kanske enbart består av en specifikation) är rättesnöret för testens utformning, testsviten ser till att koden gör vad den ska, kommentarer kan hjälpa till med att förklara hur koden gör det den ska på en nivå som kan vara fullständigt ointressant för både dokumentationen och/eller testen.

Ligger jag beroende av maskiner så hoppas jag att mjukvaran utvecklats av ett team som inte blint förespråkar en viss isolerad utvecklingsmetod framför andra beroende på vad som är "modernt" eller ej. Livsuppehållande maskiner eller kritisk styrningsmjukvara kan kräva andra metoder än vetenskaplig analyskod, som kan kräva andra metoder än webbutveckling, som kan kräva andra metoder än interna affärssystem, etc.

unit-test: visar de typiskt att varje separat modul faktiskt implementerar sitt externa API
integrations-test: visa att moduler kan kombineras via sina externa APIer på önskvärt sätt
system-test: visar t.ex. prestanda/skalbarhet uppfyller målen, har man ett GUI testar man att det är användbart

Inget av detta svarar på frågan varför du gjort på ett visst sätt. Behovet att att behöva dokumentera hur saker fungerar minskas inte heller av tester, det minskar man genom att bryta ner sitt program i mindre bitar så namnet på funktionen beskriver uppgiften och implementationen är så trivial att det är uppenbart hur den fungerar, tror alla här är överens om just detta. Här tycker jag McCabe cyclomatic complexity är ett väldigt bra hjälpmedel, håller man alla funktioner/metoder under 5-6 är logiken normalt sett trivialt, det är lämpligt att ha hårt gräns på runt 10 (går att testa automatiskt att all kod håller sig under ett visst värde).

Tror nog alla är med på detta.

Det behövs fortfarande kommenterar för varför. Det behövs också dokumentation vad externa API förväntas lösa för uppgift, lämpligen har man även exempel som visar hur APIet är tänkt att användas. Vare sig tester eller välskriven/enkel kod ersätter detta.

Läser du dokumentationen på MSDN eller tittar du i källkoden för .NET när du ska lura ut hur saker fungerar?

Vadå inte programmering? Du bygger ju upp ett utseende, inte bara på texten och var texten ska befinna sig och i vilken form utan även om du nu gör en hemsida hur den ska se ut osv. Givetvis är det programmering men det är väl inte i den mest avancerade formen

Det där står om bara HTML, som har mest med text att göra, hen jag svarade nämnde både HTML och CSS. Sedan förstår jag inte varför det inte skulle vara programmering, man skriver kod som ger instruktioner till någonting. Bara för att man inte programmerar ett program eller en maskin så är det ju fortfarande samma princip, du ger genom ett datorspråk instruktioner om utseende och vad som skall hända när man gör si och så. HTML och CSS är en form av programmering men mer inom webben, därför brukar man även kalla det webbprogrammering

Läser väldigt ofta genererad assembler när jag jobbar med prestandakritiska komponenter för att se att de konstruktioner man valt inte ställer till det för kompilatorn, skulle aldrig vilja använda något bara baserat på detta.

Har för att helt förstå saker som async/await och liknande genom att läsa CIL. Det senare är knappast ett substitut för informationen på MSDN, skulle vara extremt ineffektivt att försöka använda en ramverk/bibliotek på det sättet.

Kod utan kommenterar kring hur man ska använda produkten håller inte hög kvalité för den som ska använda den, effektivare/mer utbroderande att läsa vanligt skrivet språk som förklarar detta än läsa koden. Kod utan kommenterar kring varför kommer med stor sannolikhet få buggar introducerade i framtiden av välmenande personer som ska "förenkla" något.

Jo det är det, en länk till exempel, men sakerna som du "programmerar" är väldigt simpla helt enkelt, varför utesluter du dessa datorspråk? När jag kollar upp vad programmering är för något, så står det inte precis att det är en gräns där för simpla saker inte är inräknade. Du tycker säkert också att många företag har fel då eftersom dom använder begreppet "webbprogrammering" när dom pratar om HTML, CSS, Javascript m.m. Vet inte om det är detta du tänker på men är det så att du tänker mer på programmerare snarare än programmering? En programmerare till exempel är ju inte bara någon som skriver kod. Jag kan skriva kod, men det gör mig inte till en programmerare, utan en kodare. Men en programmerare kan skriva kod i HTML och fortfarande programmera, dock i en begränsad och enkel form. Sen kanske man brukar kalla HTML för markup language, vilket inte är fel (står ju för HyperText Markup-Language), men tycker inte det är fel att säga att det även är med i kategorin "programmering".

PS: Vet inte om det är den bästa jämförelsen men man kanske kan ta en cykel och en motorcykel, båda är inom samma kategori "cykel", båda har ett styre, två hjul osv, men den ene är bra mycket mer avancerad. Dom är inom samma kategori, men dom är inte samma sak

Alltså programmering är ju inte endast kodningen, att skriva kod. Att programmera är mycket mer än så och det gäller alla datorspråk, om du skriver i CSS eller om det är .NET, skriver man endast koden så programmerar man inte.

Simpel programmering är fortfarande programmering. "Hello World!" är det första steget för i stort sett alla programmerare. Python är ett enkelt språk, fortfarande programmering.

Företag använder ofta begrepp fel. Någon som enbart arbetar med HTML, CSS etc är inte programmerare, det är en webbdesigner.

HTML är fortfarande markup, inte programkod. Du kan inte skapa programkod med HTML.

Jo, det är fel. Du kan inte skapa ett datorprogram i ett markup-språk.

Alla försök att jämföra programmering blir dåliga, i synnerhet då de oftast är fel på ett eller annat plan.

Programmering består av mycket mer än kodknackande, ja. Det får fortfarande inte CSS att bli ett programmeringsspråk, det är markup. Du kan inte skriva ett datorprogram med CSS hur gärna du än vill.

Skillnaden är att HTML och CSS inte kan skapa en exekverbar maskinkod. Du kan inte säga att du programmerar när du inte skriver ett program.

-- Kvalar skapandet av det här in som programmering? (Det är alltså inget program i sin klassiska betydelse)
-- Jag själv brukar aktivt välja andra ord än programmering om det här.. Rolig kodning är det i vilket fall!

library ieee;
    use ieee.std_logic_1164.all;
    use ieee.numeric_std.all;

entity mac is
  port(clk : in  std_logic;
        ds : in  std_logic;
        a  : in  std_logic_vector(15 downto 0);
        b  : in  std_logic_vector(15 downto 0);
        p  : out std_logic_vector(47 downto 0);
end entity;

architecture vhdl of mac is
   signal pi : signed(p'range):=(others=>'0');
begin
   p<=std_logic_vector(pi);
   process(clk)
   begin
      if rising_edge(clk) then
         if ds='1' then
            pi<=resize(signed(a)*signed(b),pi'length);
         else
            pi<=signed(a)*signed(b)+pi;
         end if;
      end if;
   end process;
end architecture;

Jag föredrar att koden är lättläst, välkommenterad och väl dokumenterad.
Kanske någon av er föredrar något annat, men jag har svårt att förstå varför.