[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [PROGRAMMERING] Anvendelsen af Perl i dag



Michael Rasmussen <sslug@sslug> writes:

[php vs. perl]

> nu skrev jeg jo også eksplicit små eller mellemstore projekter. Om der
> er meget eller lidt kode i forhold til HTML, mener jeg er fuldstændig
> ligegyldigt, hvis valget står mellem Perl og PHP - heredoc findes i både
> PHP og Perl

Hvis man koder PHP og begynder sine php-filer med '<?php' og afslutter
dem med '?>' er den praktiske forskel til at overse. Så skal vi ned i
detaljer om man kan lide perl datatyper eller php's datatyper eller
lignende detaljer.

Der hvor jeg mener PHP har en praktisk fordel er når man også bruger
PHP som template-system. Altså hvor man laver noget ala:

<html>
<head>
  <?php 
    require 'something';
    initialize_something();
  ?>

  <links rel="style" type="text/css" src="styles.css" />
  <title><?php echo $title ?></title>
</head>
<body>
[... layout html ...]
<?php echo $content ?>
[... layout html ...]
</body>
</html>

Perl har også en række template-systemer, men man skal selv finde dem
og enten er de store og uoverskulige eller også kan de ikke
nok. (flame away...)

Hvis forholdet mellem HTML/kode er i en størelsesorden hvor heredoc er
at foretrække er stillingen lige og hvis man virkelig har brug for de
advancerede templatesystemer kan det godt være at man kan finde det
perfekte i CPAN. Jeg har ikke set templatesystemet til PHP (jeg har
helle rikke ledt), men har set nogle selvopfundne.

>> De par gange jeg har skulle lege med Java har jeg haft en dårlig smag
>> af 'There Only One Way To Do It" for nu at spille lidt på et af
>> mottoerne for Perl. Der tror jeg meget mere på .net-konceptet, der
>> virker meget mere åbent for at sprog har forskellige fordele.
>> 
> Jeg mener, den fundamentale forskel mellem Java og C# - jeg gider ikke
> bruge tid på VB - er, at Java blev konstrueret med henblik på "den
> perfekte" implemementation af et OO-sprog, mens C# er konstrueret med
> henblik på, at det skal være nemt for udviklerne.

Nu var jeg meget bevidst om at skrive '.net-konceptet' og ikke C#. Om
VB.net skal tages seriøst eller ej skal jeg ikke gøre mig til dommer
over. Pointen er mindst at tage det som proof-of-concept for at .net
søger at være forholdsvist sprogneutralt.

Mange programmøre har svært nok ved at magte et sprog og for dem er
sprogneutralitetyen underordnet. Men for nogle programmøre at det rart
at kunen vælge mellem en række af sprog og kunen vælge C# når det
giver mening og noget Haskell-lignende når det giver mening og for
folk som Gnome-folkene, for hvem det er vigtigt ikke at binde sig fast
til C++, vil det være en fordel at skulle lave et sæt kanoniske
bindinger som CIL-objekter istedet for at skulel have vedligeholdt
C-bindinger og N forskellige sprogbindinger på et højere niveau.

Hvis du har ret i din påstand om Java konstrueret som den perfekte
implementation af OO så mener jeg at de har begået hybris på den
dårlige måde. Jeg tror ikke på perfektion og jeg stoler ikke på folk
der tror på perfektion.

>> Men vil du beskrive hvilke egenskaber du tænker på når du snakker om
>> scriptsprog som ikke optimale i helt generelle termer?

> Den umiddelbare: Scriptsprog forudsætter et runtime miljø, det gør
> compileret kode ikke (Jeg ser her bort fra OS og kerne). Så længe ABI er
> konsistent, kan jeg distribuere den binære kode.

Ligeledes gør Java, men det er vel ikke et scriptingsprog?

C++ kræver også et større runtime-miljø. Det er bare normalt linket
ind som andre library. Man kan godt oversætte C++ med -nostdlic++ (tror
jeg), men så virker basalt dele af sproget som for eksempel exceptions
ikke.

C er også et scriptingsprog.
  http://root.cern.ch/root/Cint.html
  http://fabrice.bellard.free.fr/tcc/

Nej, jeg ved ikke rigtigt hvorfor, men folk har vel en grund.

> Er det konsistent på API må jeg distribuere kilden. For at sikre mig
> mod ABI-inkompatibilitet kan jeg vælge statisk link af biblioteker.

Statisk linkning er bare så 1990.

> Scriptsprog har typisk kun installeret en fælles kodebase, hvorfor jeg
> skal sikre mig, at brugerne har installeret en række udvidelser, hvis jeg
> skal være sikker på, at mit program vil kunne afvikles. F.eks. er Perl's
> GTK-bindinger ikke med i den fælles kodebase, hvorfor en
> standardinstallation vil skulle have dette installeret.

Du vil så sandelig også skulle satse på at folk har gtk installeret
hvis ikke du linker statisk. Fint med mig hvis du gør det, jeg finder
det bare spild hvis din logik fylder 1MB og din binary så fylder en
faktor 10 på grund af statisk linkning.

> Scriptsprog - dem jeg har kendskab til, er ikke typestærke. Dette er ikke
> altid en fordel, men jeg vil ofte foretrække et typestærkt sprog til
> større applikationer, da typefejl bliver afsløret på
> oversættelsestidspunktet og ikke kørselstidspunktet - testen forgår
> invitro og ikke exvitro.

Gider du lige læse http://en.wikipedia.org/wiki/Strong_typing og
overveje hvad du præcist mener med typestærkt. Det lyder som statisk
typning, men langt de fleste OO-sprog er ret dynamiske i deres typning.

-- 
 Peter Makholm     |     Have you ever felt trapped inside a Klein bottle?
 sslug@sslug |                                                      
 http://hacking.dk |                                                      


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-11-01, 02:01 CET [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *