Comments on: En minimal http-server i Ruby http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/ om livet som .net utvikler Wed, 08 Feb 2012 09:53:01 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Torbjørn http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80332 Torbjørn Mon, 22 Feb 2010 10:46:34 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80332 Det blir enda mer om diverse programmeringsspråk og paradigmer her snart.., har bl.a. så smått begynt å lære meg Haskell. Og siden du nevnte det - dynamiske programmeringsspråk er mer enn bare dynamisk typing, selv om det ofte er det vi fokuserer på. Språk er ikke bare statiske eller bare dynamiske, men befinner seg alltid et sted imellom ytterpunktene. Men mer om dette i en blogpost om en ukes tid. Det blir enda mer om diverse programmeringsspråk og paradigmer her snart.., har bl.a. så smått begynt å lære meg Haskell.

Og siden du nevnte det – dynamiske programmeringsspråk er mer enn bare dynamisk typing, selv om det ofte er det vi fokuserer på. Språk er ikke bare statiske eller bare dynamiske, men befinner seg alltid et sted imellom ytterpunktene. Men mer om dette i en blogpost om en ukes tid.

]]> By: Jonas Follesø http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80328 Jonas Follesø Mon, 22 Feb 2010 09:45:29 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80328 Jepp, Kayak vil måtte basere seg på reflection for å finne klasser som skal håndtere en request. Ønsker vi ny funksjonalitet må denne kompileres og lastes via refleksjon. Dette håndteres automatisk av Kayak, så du slipper å forholde deg til refleksjon som utvikler. Dog må du kopilere koden før den kan lastes, siden C# ikke har støtte for scripting out of the box. Når vi snakker om dynamisk funksjonalitet så handler refleksjon ikke om dynamisk tying (som i dynamiske programmerignsspråk), men dynamisk lasting av funksjonalitet (som er to forskjellige greier). Dynamisk typing får vi først i C# 4.0, og da vil man enkelt kunne f.eks laste handler filer direkte uten å måtte kompilere kode først. Mulighet å kjøre C# kompilatoren som en "service" og kompilere kode "on the fly" vil og muliggjøre C# scripting (dynamisk lasting av ukompilert kode under runtime) som ville gjort det enklere å legge til nye KayakService klasser (i dag må de kompileres). Ang. mindset så er jo det største argumentet for å lære nye språk. Man har kanskje ikke et Ruby prosjekt på jobben, men ved å lære det på fritiden kan man endre måten man tenker på, og løse problemer i C#/.NET på en mer elegant/effektiv måte ved å bruke disse ideene. Har f.eks selv hatt kjempe nytte av det jeg lærte i Funksjonell Programmering i Scheme på universitetet når jeg lærte meg LINQ, og generelt måten jeg tenker funksjonell programmering. Så kjempe flott at du kjører på med Ruby blog posts på Norsk! :) Jepp, Kayak vil måtte basere seg på reflection for å finne klasser som skal håndtere en request. Ønsker vi ny funksjonalitet må denne kompileres og lastes via refleksjon. Dette håndteres automatisk av Kayak, så du slipper å forholde deg til refleksjon som utvikler. Dog må du kopilere koden før den kan lastes, siden C# ikke har støtte for scripting out of the box.

Når vi snakker om dynamisk funksjonalitet så handler refleksjon ikke om dynamisk tying (som i dynamiske programmerignsspråk), men dynamisk lasting av funksjonalitet (som er to forskjellige greier). Dynamisk typing får vi først i C# 4.0, og da vil man enkelt kunne f.eks laste handler filer direkte uten å måtte kompilere kode først. Mulighet å kjøre C# kompilatoren som en “service” og kompilere kode “on the fly” vil og muliggjøre C# scripting (dynamisk lasting av ukompilert kode under runtime) som ville gjort det enklere å legge til nye KayakService klasser (i dag må de kompileres).

Ang. mindset så er jo det største argumentet for å lære nye språk. Man har kanskje ikke et Ruby prosjekt på jobben, men ved å lære det på fritiden kan man endre måten man tenker på, og løse problemer i C#/.NET på en mer elegant/effektiv måte ved å bruke disse ideene.

Har f.eks selv hatt kjempe nytte av det jeg lærte i Funksjonell Programmering i Scheme på universitetet når jeg lærte meg LINQ, og generelt måten jeg tenker funksjonell programmering. Så kjempe flott at du kjører på med Ruby blog posts på Norsk! :)

]]> By: Torbjørn http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80322 Torbjørn Mon, 22 Feb 2010 09:22:03 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80322 En viktig forskjell er også hvordan jeg i Ruby kan loade kode i runtime - i mitt tilfelle basert på filnavn. I C# brukte jeg reflection, og jeg antar at Kayako har implementert den biten omtrent på samme måte. Reflection er C#'s mest dynamiske feature, men siden C# ikke er særlig dynamisk i utgangspunktet er reflection noe tungvindt. En viktig forskjell er også hvordan jeg i Ruby kan loade kode i runtime – i mitt tilfelle basert på filnavn. I C# brukte jeg reflection, og jeg antar at Kayako har implementert den biten omtrent på samme måte. Reflection er C#’s mest dynamiske feature, men siden C# ikke er særlig dynamisk i utgangspunktet er reflection noe tungvindt.

]]> By: Torbjørn http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80321 Torbjørn Mon, 22 Feb 2010 09:17:50 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80321 Ja, jeg ble gjort oppmerksom på Kayak etter at jeg skrev koden min, og Kayak-løsningen er absolutt elegant. Jeg begynte heller ikke blogpostene med et mål om vise at Ruby er "bedre" enn C#, og ble selv overrasket over hvor kompakt jeg fikk Ruby'en. Jeg synes likevel mitt siste poeng, som du også var enig i, er viktig - og gjør ofte mer jobb i C# enn nødvendig. Ruby hjelper meg å endre dette mindsettet. Ja, jeg ble gjort oppmerksom på Kayak etter at jeg skrev koden min, og Kayak-løsningen er absolutt elegant. Jeg begynte heller ikke blogpostene med et mål om vise at Ruby er “bedre” enn C#, og ble selv overrasket over hvor kompakt jeg fikk Ruby’en. Jeg synes likevel mitt siste poeng, som du også var enig i, er viktig – og gjør ofte mer jobb i C# enn nødvendig. Ruby hjelper meg å endre dette mindsettet.

]]> By: Jonas Follesø http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80320 Jonas Follesø Mon, 22 Feb 2010 08:59:51 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80320 Her er et kjapt eksempel på C#/.NET løsning basert på Kayak som er en mer reel sammenligning. Fortsatt ikke like kompakt som Ruby versjonen, men samme type funksjonalitet. [Path] attributter i stedenfor responder filer, og KayakServer i stedenfor Sinatra/WEBrick. http://codepaste.net/p2d875 Kan evt. forenkles ytterligere med en generisk Kayak-modul hvor man kan sende inn lambda-uttrykk for å håndtere de forskjellige HTTP GET kallene. Her er et kjapt eksempel på C#/.NET løsning basert på Kayak som er en mer reel sammenligning. Fortsatt ikke like kompakt som Ruby versjonen, men samme type funksjonalitet. [Path] attributter i stedenfor responder filer, og KayakServer i stedenfor Sinatra/WEBrick.

http://codepaste.net/p2d875

Kan evt. forenkles ytterligere med en generisk Kayak-modul hvor man kan sende inn lambda-uttrykk for å håndtere de forskjellige HTTP GET kallene.

]]> By: Jonas Follesø http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80315 Jonas Follesø Mon, 22 Feb 2010 08:12:09 +0000 http://blog.kjempekjekt.com/2010/02/22/en-minimal-http-server-i-ruby/#comment-80315 Flott post. Dog til C#'s forsvar så er løsningene basert på forskjellige abstraksjonsnivå (selv om du sammenligner WEBRick som lavnivå HttpListener). I .NET posten går store deler av koden med på å implementere selve HTTP serveren, noe du får gratis fra WEBrick hvor du kun implementerer "handlerene". Dersom du hadde valgt et eksternt .NET bibliotek framfor HttpListener ville du kunne fått koden langt mer kompakt. Men du har et viktig poeng at du som C# utvikler over 8 år lander på en løsning på 170 linjer, mens som Ruby utvikler klarer å lande på 6 kodelinjer. Det sier litt om forskjellen i mindset når man koder Ruby og C#. .NET utviklere generelt har en tendens til å lene seg alt for tungt på Microsoft (noe ALT.NET er reaksjon på), noe som gjør at man får suboptimale dersom .NET ikke har funksjonaliteten "out of the box". Når du koder Ruby er det helt naturlig å bruke open source bibliotek som Sinatra og WEBrick. Flott post.

Dog til C#’s forsvar så er løsningene basert på forskjellige abstraksjonsnivå (selv om du sammenligner WEBRick som lavnivå HttpListener). I .NET posten går store deler av koden med på å implementere selve HTTP serveren, noe du får gratis fra WEBrick hvor du kun implementerer “handlerene”. Dersom du hadde valgt et eksternt .NET bibliotek framfor HttpListener ville du kunne fått koden langt mer kompakt.

Men du har et viktig poeng at du som C# utvikler over 8 år lander på en løsning på 170 linjer, mens som Ruby utvikler klarer å lande på 6 kodelinjer. Det sier litt om forskjellen i mindset når man koder Ruby og C#. .NET utviklere generelt har en tendens til å lene seg alt for tungt på Microsoft (noe ALT.NET er reaksjon på), noe som gjør at man får suboptimale dersom .NET ikke har funksjonaliteten “out of the box”. Når du koder Ruby er det helt naturlig å bruke open source bibliotek som Sinatra og WEBrick.

]]>