Harald Brombach (digi.no) Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Fant opp ny måte å programmere på. Nå har den norske utvikleren fått napp hos Microsoft Lenke til kommentar
Knut Yrvin Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Endelig begynner Thomas Hansen å få anerkjennelse for den meget krevende jobben han har utført for å få konseptet på lufta. Enormt mye jobb! Stå på Thomas! Nå skjer ting. Viktig. Det vil fortsatt være mye oppoverbakke framover også. Lenke til kommentar
Ompa Kaiiizer Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Eh... hva er det som er så revolusjonerende nytt her egentlig? Takker nei jeg. Lenke til kommentar
RattleBattle Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 GPLv3-lisens og en kommersiell lisens Hva er det som gjør GPL(v3) ikke-kommersiell? Lenke til kommentar
quantum Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 GPLv3-lisens og en kommersiell lisens Hva er det som gjør GPL(v3) ikke-kommersiell? Tror han refererer til softwaren som er lisensiert og ikke selve lisensen ... Lenke til kommentar
quantum Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Eh... hva er det som er så revolusjonerende nytt her egentlig? Takker nei jeg. For meg ser det litt ut som argument-lister erstatter interfacer. Klart ting blir enda løsere knytta sammen på den måten, men hvor lurt er det? Liker at kompilatoren fanger feil og ikke kunden i runtime .... Og hvis noen som forstår bæret av dette kunne forklare forskjellen i forhold til DI-rammeverk som Spring, JEE CDI og lignende? Lenke til kommentar
quantum Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Endelig begynner Thomas Hansen å få anerkjennelse for den meget krevende jobben han har utført for å få konseptet på lufta. Enormt mye jobb! Stå på Thomas! Nå skjer ting. Viktig. Det vil fortsatt være mye oppoverbakke framover også. Du kjenner jo til dette her, må innrømme at jeg ikke ble enormt klok av MSDN-artikkelen. To spørsmål som reiser seg, basert på min sikkert manglende oversikt: Disse argument-listene, som sikkert kan være helt dynamiske; Hvorfor er det lurt å eliminere metode-signaturer? Går det an å forklare hva dette er vs. vanlige DI-rammeverk som Spring, JEE_CDI ol.? Lenke til kommentar
Emancipate Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 GPLv3-lisens og en kommersiell lisens Hva er det som gjør GPL(v3) ikke-kommersiell? At man må dele kildekoden, dersom man har endret på den. Det trenger man ikke med en kommersiell lisens. (Dette er generell info, uten at jeg har satt meg inn i akkurat denne kommersielle lisensen.) Lenke til kommentar
RattleBattle Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 At man må dele kildekoden, dersom man har endret på den. Det trenger man ikke med en kommersiell lisens. (Dette er generell info, uten at jeg har satt meg inn i akkurat denne kommersielle lisensen.) Du får høre med en Stallman hva han synes om å omtale GPL som "ikke-kommersiell". Du vil sannsynligvis få en dask eller tre i ansiktet ;-). Det er ingen ting som hindrer noen i å bruke GPL-kode kommersielt og tjene penger på det. Det er ingen motsetning i GPL og kommersiell software, selv om mange tror det. Inkludert artikkelforfatteren. Lenke til kommentar
Emancipate Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 (endret) Å måtte dele kildekoden kan selvsagt være en ulempe for kommersiell bruk. Det står heller ikke at GPL er ikke-kommersiell. Jeg tolket spørsmålet ditt bokstavelig, kanskje det var ment retorisk? Edit: Du kan også tolke det slik at kommersiell lisens = lisens som Thomas Hansen tjener penger på. At det handler om selger, ikke kjøper. Endret 7. mars 2017 av Emancipate Lenke til kommentar
PRPS448S Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Det må da bli utrolig vanskelig å vedlikeholde et stort system bygget opp på denne måten? Magic strings overalt; I atributtet på metodene, parametre, kall av metodene.. Feil blir først oppdaget ved runtime.. Ser med gru frem til den dagen jeg blir satt til å refakorere noen klasser i et slikt system. Lenke til kommentar
Spoki0 Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Var det ikke dette som også hadde eliminert alle sikkerhetshull og andre smådrøye påstander...? Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Endelig begynner Thomas Hansen å få anerkjennelse for den meget krevende jobben han har utført for å få konseptet på lufta. Enormt mye jobb! Stå på Thomas! Nå skjer ting. Viktig. Det vil fortsatt være mye oppoverbakke framover også. Takker kompis Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Eh... hva er det som er så revolusjonerende nytt her egentlig? Takker nei jeg. For meg ser det litt ut som argument-lister erstatter interfacer. Klart ting blir enda løsere knytta sammen på den måten, men hvor lurt er det? Liker at kompilatoren fanger feil og ikke kunden i runtime .... Og hvis noen som forstår bæret av dette kunne forklare forskjellen i forhold til DI-rammeverk som Spring, JEE CDI og lignende? Du burde se litt mer på "Hyperlambda". Det tillater "orkestrering" av komponenter, og blir slik en "løs binding av strongly typed kompilerte CLR moduler", kan en argumentere. I så måte, velger du selv hvor mye du ønsker å utvikle i C# (strongly typed), og hvor mye du ønsker å "orkestrere" i Hyperlambda. Hyperlambda, er ekstremt "weakly typed", sannsynligvis det mest dynamiske og løst bundet programmeringsspråket på kloden. Hvis du tror at weakly typing, og dynamiske språk har verdi, så har P5 verdi. Paradokset er at det samme er sant hvis du tror at strongly typed språk har verdi ... Men den virkelige styrken ligger i simplisiteten av konstruering av domenespesifikke språk, for løsing av dine egne domenespesifikke problemer. Samtlige "keywords" er faktisk bare løselige bundete Active Events ... Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 GPLv3-lisens og en kommersiell lisens Hva er det som gjør GPL(v3) ikke-kommersiell? Jeg forsøker selv å omtale det som "proprietær lisens" der hvor jeg vet at det er forståelse for hva den subtile forskjellen betyr. For de fleste utviklere dog da, så vil "proprietær lisens" vare equivalent med "kommersiell lisens", da de fleste Norske utviklere, i hvert falt profesjonelt, stort sett utvikler "proprietær kode". Men du preiker for korgutta her da. Uansett, så er det likegyldig for meg hva slags lisens folk bruker, og jeg vil forsøke å supportere alle likt, så lenge de er villige til å spørre i det offentlige rom, og få et svar i det offentlige rom - Siden da support til de som bruker GPL versjonen, ofte uten å betale meg, kan gjenbrukes til også de som har betalt for en "proprietær lisens". Men jeg har ikke så lyst til å diskutere dette må jeg innrømme. Jeg forsøker forøvrig også å kalle Linux for GNU/Linux, minst en gang hver dag ... Hilsen "en hacker" (som nesten ingen i Norge forstår den virkelige betydningen av) ... (Hint; Thomas Hansen) Men det med språk er vanskelig. Av og til blir en sitert feil også, uten at jeg skal skylde på Harald her. Jeg er stort sett utelukkende fornøyd med den jobben han gjorde med artikkelen her. Et misvisende sitat, uansett om det stammer fra meg, eller Harald, er irrelevant, så lenge poenget kommer frem. Og det synes jeg det gjør ... 4 Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Disse argument-listene, som sikkert kan være helt dynamiske; Hvorfor er det lurt å eliminere metode-signaturer? Det er ikke *alltid* lurt forøvrig, men av og til er det veldig behagelig (og også lurt), spesielt der hvor en muligens ønsker at forskjellige ting skal skje. Prøv å bytt ut "SaveToDataBase" i dine egne løsninger med "PushToWebService" eller "SaveToFile", så vil du raskt merke hvorfor det (ofte) er lurt ... Tenk; "Agil software" ... 1 Lenke til kommentar
Jens Evensen Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Synes P5 bærer mer preg av å være mer et rammeverk som enkapsulerer flere nyttige triks fra forskjellige "plattformer", enn et programmeringsspråk. Foreløpig i hvert fall. Kanskje ideen blir tatt videre og havner der etterhvert? Uansett. Er det gjort noe ytelsestesting på dette? Jeg ser for meg at det kan bli tungt med så mye bruk av reflection i .NET. Sikkerheten kan jo også bli en issue når det er åpen kildekode og man strengt tatt bare kan bytte ut et assembly for å kjøre sin egen kode, run-time. Eller er det mekanismer som skal hindre dette? (leste ikke all koden linje for linje). De må i hvert fall komme hvis de ikke allerede er der. Hvis ikke blir jo dette en måte for alle å kjøre hva som helst av kode uten at man har noen mulighet til å stoppe det. Jeg har trøbbel med å se ting her jeg ikke kan løse med MVVM-Light-rammeverket i WPF omtrent ut av boksen kombinert med XAML (blandt anne ved bruk av messaging i MVVM-light), men det er det er jo noe annet enn web-utvikling. Gjør kanskje koden front-end noe mer oversiktlig, men så langt jeg kan se er det en stor pris å betale på ytelse og vedlikeholdbarhet her. Foreløpig i hvert fall. "Språket" fremstår som litt proprietært, og må ha stor ubredelse for at det skal være interessant å skrive IDE'er som støtter opp under refactoring og bedre organisering av orkestrering. Uansett en stor innsats som er lagt inn her. *anerkjennende nikk for innsatsen* Hilsen Jens Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Synes P5 bærer mer preg av å være mer et rammeverk som enkapsulerer flere nyttige triks fra forskjellige "plattformer", enn et programmeringsspråk. Foreløpig i hvert fall. Kanskje ideen blir tatt videre og havner der etterhvert? Uansett. Er det gjort noe ytelsestesting på dette? Jeg ser for meg at det kan bli tungt med så mye bruk av reflection i .NET. Sikkerheten kan jo også bli en issue når det er åpen kildekode og man strengt tatt bare kan bytte ut et assembly for å kjøre sin egen kode, run-time. Eller er det mekanismer som skal hindre dette? (leste ikke all koden linje for linje). De må i hvert fall komme hvis de ikke allerede er der. Hvis ikke blir jo dette en måte for alle å kjøre hva som helst av kode uten at man har noen mulighet til å stoppe det. Jeg har trøbbel med å se ting her jeg ikke kan løse med MVVM-Light-rammeverket i WPF omtrent ut av boksen kombinert med XAML (blandt anne ved bruk av messaging i MVVM-light), men det er det er jo noe annet enn web-utvikling. Gjør kanskje koden front-end noe mer oversiktlig, men så langt jeg kan se er det en stor pris å betale på ytelse og vedlikeholdbarhet her. Foreløpig i hvert fall. "Språket" fremstår som litt proprietært, og må ha stor ubredelse for at det skal være interessant å skrive IDE'er som støtter opp under refactoring og bedre organisering av orkestrering. Uansett en stor innsats som er lagt inn her. *anerkjennende nikk for innsatsen* Hilsen Jens Takker I det øyeblikket man har skrivetilgang til "bin" folderen i en web app (ASP.NET), så er man vel stort sett ganske langt ute å kjøre, uansett, eller ...? Altså; Hvis serveren er kompromittert, slik at fremmede kan laste opp DLL'er til "bin" folderen, så tror jeg kanskje du har andre og større problemer enn at "Active Events kan kalles opp i vilkårlige DLL'er" ...? Ytelsen er forøvrig, noe som jeg selv åpent innrømmer, ikke i nærheten av for eksempel et metodekall, med kall gjennom en VFP. Altså en virtuell function pointer (virtuell metode). Hvis ytelse er et problem i et spesifikt område, kan man uansett enkelt enkapsulere denne biten inn i "rå C#", og kun bruke Hyperlambda for å initielt invokere denne delen. Alt som kan gjøres fra Hyperlambda, kan også gjøres fra C#. Ytelse er uansett noe jeg er ærlig på ikke er krempunktet, og årsaken til at man bør velge dette. Ville neppe mekka polygonmaskinen min til mitt neste 3D spill i Hyperlambda, for å si det slik. Dog for forms apps, og det som utgjør 95% av arbeidet til Norske programvarehus, så er dette en ikke-issue, og enkelhet i kode, og vedlikehold, vil uansett for denne typen applikasjoner ofte ha mer innvirkning på ytelse ... Jeg har selv jobbet i firmaer som har vedlikeholdt prosjekter i C++, som vår så mye spaghetti, at kompileringen krevde stasjonære PC'er, og kjøring av nevnte applikasjoner hadde maskinvarekrav, som ville fått selv NASA til å lure på om de var i stand til å kjøre disse programmene. Disse var utviklet i C++, men gikk i "kjelleren" på grunn av at koden var så rotete, at man hadde åpning, lesning og lagring av samme konfigurasjonsfil, dusinvis av gang, åpning/lesing/lukking av databasen, 20 ganger, osv, osv, osv - Før splashscreen ble vist. Rett og slett fordi systemet bestod av 1,5 million linjer med "Spaghetti" ... Og det var umulig å prøve å løse problemer, uten å risikere at systemet rett og slett ikke startet ... For å lage rask programvare, må man kunne være i stand til å beholde oversikten over hva som skjer i programvaren. Hvis man ikke har oversikten, så kan man glemme ytelse - Dette er sant selv om man utvikler i x86 Assembly. Jeg liker å tro, og mener at jeg kan tildels bevise, at det er enklere å beholde oversikten over "hva som skjer", hvis man utvikler i Hyperlambda. Da blir det endelige resultatet paradoksalt _raskere_ programvare, selv om språket i utgangspunktet er tregere ... Forøvrig ble de samme argumentene brukt imot C# i sin tid, og Java i sin tid. Say no more ... Hadde vi kodet for maks ytelse, hadde vi alle sammen uansett kodet i Assembly. Til og med C++ er "tregt" sammenlignet med Assembly ... Et godt eksempel på hvor Hyperlambda er "raskere" enn C#, kan illustreres ved følgende kodesnutt jeg selv optimaliserte en gang; string foo = ""; using (StreamReader sr = File.OpenText (somePath)) { foo += sr.ReadLine () + "\r\n"; } Ovenstående kodesnutt kan muligens se ut som dårlig kode for en erfaren programmerer, og det er fordi det ER dårlig kode. De fleste utviklere skjønner dog ikke *hvorfor* dette er dårlig kode, og ville glatt kopiert den inn i sitt eget prosjekt, for å lese en tekstfil, uten forståelsen for at dette er 3-5 størrelsesordener tregere enn å bruke "ReadToEnd", som gir samme resultatet ... I forhold til MVVM, så kan det godt hende at du har rett, uten at jeg er i stand til å verifisere det, siden jeg kan null og niks om XAML og WPF. Nå er jo P5 *web* da, så det blir vel neppe adekvat sammenligning da. Bygger man med WPF, er man vel i praksis låst inne til å levere app'en sin for Windows, eller ...? De fleste som vil bruke P5, vil jeg tro mekker web ting, hvor portabilitet, og kjøring på alt er alfa og omega. Når det uansett krever nettverkshopp og ruting, over internett, i tillegg til rendering og parsing av HTML, download av CSS + eksekvering av JS, osv, osv, osv. Så blir forskjellen på en web app utviklet i assembly, og en utviklet i Hyperlambda, tilnærmet lik null, til syvende og sist. Og brukeren vil oppleve begge versjonene som like kjappe ... Som jeg sier i MSDN artikkelen, hvorvidt det tar 5 klokkesykluser eller 5.000 klokkesykluser og kalle "SaveToDataBase" er irrelevant, så lenge implementasjonen tar 5.000.000 klokkesykluser. De fleste applikasjoner jeg ser for meg er adekvate å utvikle i Hyperlambda, er den type jeg selv har jobbet mye med gjennom tidene. Og dette er; * Regnskapprogramvare * Forms apps generelt * Datasamling * Osv ... Skal du utvikle ting hvor ytelse er alfa og omega, bør du bruke noe annet. Paradoksalt er da, at hvis Hyperlambda er for tregt, så er da også ofte Java og C# for tregt, og til og med C++ "questionable" ... Forøvrig takker for intelligente spørsmål. Me like good questions 2 Lenke til kommentar
2J37JHPB Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Uansett. Er det gjort noe ytelsestesting på dette? PS, glemte en "while" loop i eksempelet mitt ... Lenke til kommentar
quantum Skrevet 7. mars 2017 Del Skrevet 7. mars 2017 Disse argument-listene, som sikkert kan være helt dynamiske; Hvorfor er det lurt å eliminere metode-signaturer? Det er ikke *alltid* lurt forøvrig, men av og til er det veldig behagelig (og også lurt), spesielt der hvor en muligens ønsker at forskjellige ting skal skje. Prøv å bytt ut "SaveToDataBase" i dine egne løsninger med "PushToWebService" eller "SaveToFile", så vil du raskt merke hvorfor det (ofte) er lurt ... Tenk; "Agil software" ... tenk agile ja, ble littnlite konkret dette, får nok heller titte på githuben din 1 Lenke til kommentar
Anbefalte innlegg