Schrift
[thread]3654[/thread]

PostgreSQL stored procedures ansprechen: wie kann ich das mit Perl managen? (Seite 3)



<< |< 1 2 3 >| >> 26 Einträge, 3 Seiten
steffenw
 2006-01-23 19:45
#33965 #33965
User since
2003-08-15
692 Artikel
BenutzerIn
[Homepage] [default_avatar]
@pug, Du darfst nicht vergessen, daß Du Dich in Deutschland befindest. Um Dich herum ist Europa und da ist schon alles anders, als auf der Welt ansich. Ich kenne auch Leute, die blöde Sprüche über Perl sagen. Genau gesagt ist es Neid. Genau die sellben Leute sagen dann auch: Wenn Du mir die Daten nicht genau so liefern kannst, wie ich es vorschreibe, dann geht es nicht. So etwas ist mir in Perl noch nie passiert, es geht immer. Wenn man Perl programmiert, und das hast Du bestätigt, dann hat man einfach gute Entwicklungszeiten und das auch, oder gerade wenn man sehr sauberen und strukturierten Code schreibt. Und Perl 6 bringt noch mehr Strukturmöglichkeiten und räumt mit alten Dingen auf. Ein Beispiel:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Perl 5
my $string1 = 'Hallo';
my $string2 = 'Welt';
mysub($string1, $string2);

sub mysub {
 for my $string1 ($_[0]) {
   for my $string2 ($_[1]) {
      # Ich will hier nicht $_[???] verwenden, und auch keine Referenzen und trotzdem die Variablen im Hauptprogramm beschreiben können.
     $string1 = 'sag';
     $string2 = 'ich';
   }
 }
}

In Perl 6 gibt es den Operator := und das ist viel schöner und auch viel besser strukturiert und nicht der workaround, nur mit for den Alias bilden zu können.

Wenn Du Dir die Entwicklungen der Programmiersprachen anschaust, dann werden zunehmend Interpreter für die Verarbeitung von Bytecode eingesetzt. Um das nicht so direkt zu sagen, verschleiert man das und erfindet immer neue Namen für ein und dasselbe Ding. Es geht auch nicht mehr anders, wenn man flexibel programmieren will und muß, dann kann man nicht mehr alles deklarieren und schon gar nicht das, was man sowieso nicht wissen kann, wie das die traditionellen Programmiersprachen vorschreiben. Die Flexibilität kommt also nicht von einigen Perl-Compilerentwicklern, sondern sind echte Kundenanforderungen. Perl ist eine Programmiersprache, die nur sehr wenig Ausnahmen beinhaltet, das heißt, wenn ein Leistungsmerkmal integriert wird, dann kann man es überall und in jedem Kontext einsetzten. Z.B die Listen, die hat man in anderen Programmiersprachen auch, nur kann man sie nur in bestimmten Kostrukten verwenden. Und so zieht sich das durch. Klar, wenn das so ein Fremdling Pipes mit join, sort, map und/oder grep sieht, setzt sein funktionales Gedächtnis schon mal massive Hemmschwellen.

Schaue Dir man die Codezeilen Perl von Deinen Kritikern an, wahrscheilich lachst Du Dich tot. Noch wahrscheinlicher ist, daß die Leute wahrscheilich gar nicht wissen, worüber sie reden. Irgendwo wird etwas aufgeschnappt von frustrierten Leuten. Perl ist nicht einfach, das gebe ich zu, wenn man es richtig machen will. Schon die Massen von Operatoren, die es gibt, die muß man alle erlernen und dann noch wissen, was sie in welchem Kontext machen. Aber wenn man das erst einmal begriffen hat, ist Perl ein Kinderspiel. Man muß sich nur gefallen lassen, daß man bei jeder Zeile überwacht wird, weil man alle Möglichkeiten natürlich eingeschaltet hat. Das ist aber keine Einschrännkung in Bezug auf Freiheit und Kreativität. Ich muß nicht die Millonen von Funktionsklammern schreiben, um meinen Compiler zu befriedigen, es reicht, wenn man das Programm gut lesen kann.\n\n

<!--EDIT|steffenw|1138039234-->
$SIG{USER} = sub {love 'Perl' or die};
nepos
 2006-01-23 20:31
#33966 #33966
User since
2005-08-17
1420 Artikel
BenutzerIn
[Homepage] [default_avatar]
Moechte auch mal am Rande behaupten, dass C und C++, was ja oft als die super Sprachen hingestellt werden, sicher nicht weniger fehleranfaellig sind. Fuer meine Begriffe eher mehr ;)
Natuerlich kommt es auch immer darauf an, was man nun machen will. Fuer Webanwendungen wuerd ich jedenfalls Perl nehmen. Und das DBI-Interface is auch eines der schoeneren, die ich bis jetzt gesehen hab. Da sieht C# z.B. meines Erachtens echt armselig aus. Je nach Datenbank muss ich da andere Objekte nutzen?!
pug
 2006-01-23 21:27
#33967 #33967
User since
2005-08-17
91 Artikel
BenutzerIn
[default_avatar]
Vom Thema sind wir ja ganz schön rumgekommen :-) Naja ich bin im Moment am kämpfen mit PostgreSQL und den Veränderungen, die sich durch die neue Version 8.1 ergeben. Das ist der Kern meines momentanen Problems.

Und was Perl6 angeht, da komme ich nach Bochum! Nächstes Semester möchte ich an meiner Fachhochschule "Web-Basierte-Anwendungen" mit Catalyst machen und hoffe daß ich einen Komilitonen dafür gewinnen kann.

Gruss Christian
Ein Betriebssystem sie zu knechten, sie alle zu finden, Ins Dunkel zu treiben und ewig zu binden.

William Gates III
renee
 2006-01-24 00:21
#33968 #33968
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
In Bochum wird es auch eine Diskussionen ueber Perl und die Zukunft geben...
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
Gast Gast
 2006-01-30 21:55
#33969 #33969
[quote=nepos,22.01.2006, 16:28]Gerade bei Postgres bringt dir prepare+execute keine Vorteile in der Geschwindigkeit. Aber das nur am Rande :)[/quote]
Aus PG 8.0.3 Documentation:
PREPARE
Name
PREPARE -- prepare a statement for execution
PREPARE creates a prepared statement. A prepared statement is a server-side object that can be used to optimize performance. When the PREPARE statement is executed, the specified statement is parsed, rewritten, and planned. When an EXECUTE command is subsequently issued, the prepared statement need only be executed. Thus, the parsing, rewriting, and planning stages are only performed once, instead of every time the statement is executed.

Ch.Lamprecht
nepos
 2006-01-31 01:23
#33970 #33970
User since
2005-08-17
1420 Artikel
BenutzerIn
[Homepage] [default_avatar]
Scheint neu zu sein. In der Doku, die ich habe, stand noch, dass es nix bringt :)
Wieder was gelernt ;)
<< |< 1 2 3 >| >> 26 Einträge, 3 Seiten



View all threads created 2006-01-20 15:37.