Kann man mit Perl...

[Daniel Milson]

... und Sockets unter Win32 all das machen was man auch mit C++ und Sockets kann oder kann C++ mehr?
Und gibt es eine Möglichkeit mit Perl eigene Pakete unter win32 zu erstellen?

mfg
D.M.

[ronny]

hi,
prinzipell kann man mit jeder programmiersprache alles machen - ist nur eine frage des mehraufwands.
will sagen, deine frage ist nicht besonders clever. etwas konkreter wäre besser.
mfg, ronny

[Daniel Milson]

Hi,

prinzipell kann man mit jeder programmiersprache alles machen - ist nur eine frage des mehraufwands.

Nun ja, ob man wirklich _alles_ mit _jeder_ Sprache machen kann...

will sagen, deine frage ist nicht besonders clever. etwas konkreter wäre besser.

Gut ich versuchs mal:

Also ich möchte primär Internetanwendungen schreiben die auf Sockets basieren und das auf einer Windows NT Plattform. Beispiele wären FTP Programme, Verschlüsselter Datenaustausch (ähnlich VPN), Passwortschutz mit/anhand IP Erkennung, Netzwerk-Authetifizierung über speziellen Code _in_ Paketen, Pakete verschlüsseln/abfangen/blocken etc.

So, mit C++ geht sowas sicherlich nur kann ich kein C sondern Perl :) Jetzt frage ich mich ob es möglich ist unter einer Win32 Umgebung diese Aufgaben mit Perl zu bewältigen oder ob ich C benutzten muß.

Z.B. habe ich mal danach gesucht wie man mit Perl selbst Pakete erstellen kann und habe das Paket RAW::IP gefunden,... welches aber _nur_ für Unix & CO gemacht wurde :(

Besser ausgedrückt?

mfg
D.M.

[ronny]

hi,

Nun ja, ob man wirklich _alles_ mit _jeder_ Sprache machen kann...

die theorie der informatik sagt: ja! *g*

Besser ausgedrückt?

ja. ok, also prinzipell wird vieles davon mit perl gehen (suche mal genauer im cspan), aber ich glaube kaum, daß es echt sinnvoll ist. c++ (oder java o.s.) ist für die von dir angedachten probleme wirklich geeigneter (performenz, strukturierung, usw). es gibt zwar immer mal wieder großprojekte mit perl, aber mit anderen bist du einfach schneller.
btw, sagt man doch, daß man mindest eine programmiersprache pro jahr lernen sollte. das klingt zwar erst einmal blöd, ist aber wahr.

mfg,
ronny

[Daniel Milson]

Hi,

btw, sagt man doch, daß man mindest eine programmiersprache pro jahr lernen sollte. das klingt zwar erst einmal blöd, ist aber wahr.

Naja ich denke dann werde ich das wohl tun :)

Vielen Dank nochmal

mfg
D.M.

[klaus]

Hallo,

ja. ok, also prinzipell wird vieles davon mit perl gehen...

Vieles?
<cite aus perlfunc>
Low-level socket functions
     accept, bind, connect, getpeername, getsockname, getsockopt, listen, recv, send,
     setsockopt, shutdown, socket, socketpair
</cite>
is alles da, was auch in c++ da ist. Wohlgemerkt Lowlevel.
Im CPAN-Archiv gibts genug Module, welche verschiedenste Protokolle abdecken (LWP ist da nur _ein_ Beispiel).

...aber ich glaube kaum, daß es echt sinnvoll ist.

Heerscharen von Progammierern können sich wohl nicht irren.

...aber mit anderen bist du einfach schneller.

Beim Implementieren sicher nicht.
Gerade in der Entwickelungsperformance sehe ich die Stärke von Perl. Und sie ist kontaktfreudig (Kapitel 6. 'Social Engineering' aus 'Programmieren in Perl')
Die Performance ist zwar nicht mit der eines C-Programmes vergleichbar, aber wenn die Netzanbindung nicht gerade atemberaubend ist, dann reicht sie wohl aus.

Und es sind außerdem noch Dinge miteingebaut, welche in C++ erst mal entwickelt gehören.

Einfach mal ausprobieren
Grüße
Klaus

[ronny]

Hallo,

ja. ok, also prinzipell wird vieles davon mit perl gehen...  
Vieles?

ok, ich wußte es nicht 100% und dann relativiere ich es vorsichtsichtshalber. ;)

Gerade in der Entwickelungsperformance sehe ich die Stärke von Perl. Und sie ist kontaktfreudig (Kapitel 6. 'Social Engineering' aus 'Programmieren in Perl')

kann ich wirklich nicht teilen. die c, c++ und java-gemeinde ist garantiert nicht kleiner und auch sehr gesprächig. ohne die verdienste des cspans zu schmällern, aber du findest garantiert mehr module/addons/bibliotheken für c oder java. das problem ist aber mehr, daß perl als solches gewisse probleme hat, die das software engineering nicht gerade vereinfachen. das geht bei fehlenden tools los (ide?, gute(!) syntaxchecker) und endet bei grundsätzlichen problemen der sprache. so neigt man bei perl doch eher zu dirty hacks (was für adminscripte sicherlich optimal ist, aber fü echte softwareentwicklung?) im gegensatz zu java und c++ ist das objektmodel sicherlich auch nicht gerade optimal.

Die Performance ist zwar nicht mit der eines C-Programmes vergleichbar, aber wenn die Netzanbindung nicht gerade atemberaubend ist, dann reicht sie wohl aus.

das ist natürlich eine frage der anwendung (darauf zielte auch meine anfängliche frage). wie schon einmal gesagt, liegt der performenznachteil aber nicht nur bei 10%, sondern eher bei faktor 10.

Und es sind außerdem noch Dinge miteingebaut, welche in C++ erst mal entwickelt gehören.

an was dachtest du da? ich halte es übrigens nicht zwangsweise für einen vorteil, daß es perl *alles* sofort kann. ein modulmodell ist für meine begriffe besser und gerade mit fähigkeiten wie überladbare operatoren sicher gut realisierbar.

cu ronny

[klaus]

Hallo,

Gerade in der Entwickelungsperformance sehe ich die Stärke von Perl. Und sie ist kontaktfreudig (Kapitel 6. 'Social Engineering' aus 'Programmieren in Perl')
kann ich wirklich nicht teilen. die c, c++ und java-gemeinde ist garantiert nicht kleiner und auch sehr gesprächig. ohne die verdienste des cspans zu schmällern.

mit kontaktfreudig meinte ich, daß Perl über viele Mechanismen verfügt, um Anschluß zu anderen Systemen zu finden (Netzwerk, Prozesse, Sprachen...)

das problem ist aber mehr, daß perl als solches gewisse probleme hat, die das software engineering nicht gerade vereinfachen.
das geht bei fehlenden tools los (ide?, gute(!) syntaxchecker) und endet bei grundsätzlichen problemen der sprache.

naja mit einem Syntaxchecker kann ich helfen: 'Perl -c', ist eingeabut, und wenn's zur Laufzeit Probleme gibt, sind Perl's Fehlermeldungen recht verständlich.
Und eine Ide mag ich nicht, auch in C nicht. Ein guter Editor (Emacs vielleicht) hat für mich immer ausgereicht. Naja ich bin halt ein Fossil, was das angeht.

so neigt man bei perl doch eher zu dirty hacks (was für adminscripte sicherlich optimal ist, aber fü echte softwareentwicklung?)

In Perl sind 'dirty hacks' möglich, aber Du kannst Dir auch strengere Auflagen beim Programmieren machen. Es hängt von Dir ab, wie sauber Du bist. Das einzige, das 'fehlt' sind Datentypen. Aber ich hab das eigentlich nie als Nachteil empfunden, da ich sowieso eine gewisse Disziplin gewohnt bin.
Und daß in C++ z.B. auch Müll produziert werden kann, hab' ich letzte Woche  gesehen. 100 KByte Code zum wegschmeißen. Unwartbar.
Echte Softwareentwicklung passiert im Kopf und nicht in einer Sprache. Wenn Du nicht bereit  bist, strukturiert zu arbeiten, kannst Du in jeder Sprache Müll produzieren. Andererseits kannst Du mit jeder Sprache auch sauber arbeiten, wenn Du nur willst.

an was dachtest du da? ich halte es übrigens nicht zwangsweise für einen vorteil, daß es perl *alles* sofort kann.

Perl kann bei weitem nicht *alles*, muß es auch nicht. Es kann aber vieles, um 'einfach Dinge einfach zu erledingen, und schwere Dinge möglich zu machen'.
Ich will jetzt nicht sagen, daß Perl ein Ersatz für irgendeine andere Sprache ist (sh vielleicht). Mit den Sprachen ist's wie mit Menschen, gut daß es Unterschiede gibt. Ich mach auch nicht alles in Perl, nur weil ich Perl toll finde.
Ein Rolls Royce ist ein tolles Auto, aber damit Schotter transportieren ist nicht empfehlenswert, da gibts geeignetere Fahrzeuge.
So seh' ich auch die einzelnen Sprachen.
Ich verwende halt das, was mir am geeignetsten erscheint, ein Problem zu lösen.

Aber was red ich da, jedem das seine und mir das meine
Klaus

[ronny]

Hallo,

mit kontaktfreudig meinte ich, daß Perl über viele Mechanismen verfügt, um Anschluß zu anderen Systemen zu finden (Netzwerk, Prozesse, Sprachen...)

ok, daß ist aber mit java und c++ auch kein problem.

naja mit einem Syntaxchecker kann ich helfen: 'Perl -c', ist eingeabut

ich denke, du weißt, was ich mein. *g*

und wenn's zur Laufzeit Probleme gibt, sind Perl's Fehlermeldungen recht verständlich.

schon, aber einem enduser sagt es trotzdem nichts. das ist sicher ein prinzipelles problem von interpretativen sprachen, aber ein richtiger syntaxchecker kann die entwicklungszeit doch extrem senken.

Und eine Ide mag ich nicht, auch in C nicht. Ein guter Editor (Emacs vielleicht) hat für mich immer ausgereicht. Naja ich bin halt ein Fossil, was das angeht.

oh, ich gehöre auch zu den emacs-fans. aber um gui zu bauen, gibt's bestimmt bessere alternativen (4gl?).

Es hängt von Dir ab, wie sauber Du bist.

richtig. aber wenn ich quellcodes bekomme, ist es halt teilweise sehr schwierg (was ist oop???)

Das einzige, das 'fehlt' sind Datentypen.

das meinte ich u.a. mit dirty hacks. ich meine, daß geht mit c natürlich auch, aber es ist nur ein hack und man weiß es. in perl macht das aber jeder trottel in seien scripten und man kann das teilweise echt kaum noch lesen.

Und daß in C++ z.B. auch Müll produziert werden kann, hab' ich letzte Woche  gesehen.

keine frage, aber z.b in java wird dir das schon sehr schwer fallen.

Echte Softwareentwicklung passiert im Kopf und nicht in einer Sprache.

[x] agree

Wenn Du nicht bereit  bist, strukturiert zu arbeiten, kannst Du in jeder Sprache Müll produzieren.

[x] agree

Andererseits kannst Du mit jeder Sprache auch sauber arbeiten, wenn Du nur willst.

[x] agree

ABER: insbesonder java (und eigentlich auch c++) unterstützt dich auf dem weg zur sauberen programmierung.

Perl kann bei weitem nicht *alles*, muß es auch nicht. Es kann aber vieles, um 'einfach Dinge einfach zu erledingen, und schwere Dinge möglich zu machen'.

ja, da gebe ich dir vollkommen recht. trotzdem sollte man zwischen adminhacks und anwendungsentwicklung differenziern.

Ich will jetzt nicht sagen, daß Perl ein Ersatz für irgendeine andere Sprache ist (sh vielleicht).

wahrscheinlich nicht 'mal für sh. *g*

Mit den Sprachen ist's wie mit Menschen, gut daß es Unterschiede gibt. Ich mach auch nicht alles in Perl, nur weil ich Perl toll finde.

[x] agree

Ich verwende halt das, was mir am geeignetsten erscheint, ein Problem zu lösen.

[x] agree; genau das wollte ich sagen: perl ist cool für viele dinge, aber eben nicht für professionelle anwendungsentwicklung.

» Aber was red ich da, jedem das seine und mir das meine
[x] last agree

cu ronny

[klaus]

hallo ronny,

Die menge 'agree' haben mich wirklich gefreut, da ich daren sehe, daß wir eigentlich in den wirklich wesenlichen Punkten ja eh einer Meinung sind.
Meine Ansciht über 'professionelle' Softwareentwicklung ist eben, daß _ich_ so wsauber wie Möglich arbeite.
Was andere tun, kann ich nur im begrenzten Maße beeinflussen.
Und daß es überall DA*'s gibt, daß ist eben Tatsache. Es gibt auch Leute, die meinen, weil sie Linux schreiben können, sind sie _die_ Spezialisten.
Leute, die irgendwas zusammendrehen, sollen das auch tun. Sie werdens meist nicht lange tun. Qualität der eigenen Arbeit ist im Endeffekt immer der Garant für weitere Aufträge.

Und...
Perl ist eine Scriptsprache, die viel kann. Das sollte keiner vergessen.
Bis jetzt bin ich noch nicht auf die Idee gekommen, in Perl eine reine Applikation zu schreiben.
ach ja, Ausgangspunkt war die Frage von Daniel

Wie kann man mit Perl und Sockets unter Win32 all das machen was man auch mit C++ und Sockets kann oder kann C++ mehr?
Und gibt es eine Möglichkeit mit Perl eigene Pakete unter win32 zu erstellen?

1.) Perl benutzt die gleichen Socket-Funktionen wie C++. Deshalb kann man auch das mach was in C++ grundsätzlich möglich ist
2:) Es gint die Möglichkeit unter Win32 eigene Pakete zu erstelllen.
Es ging ja nicht darum in Perl einen Browser zu schreiben oder eine IDE oder eine Tabellenkalkulation.
Das sollten wir nicht vergessen!

Bis dann
Klaus

BTW.: Ich hab gestern ein bißchen von Larry's Ideen zu Perl 6 gelesen. Hat großartiges vor. http://www.perl.org/perl6/

[ronny]

hallo klaus,

wir eigentlich in den wirklich wesenlichen Punkten ja eh einer Meinung sind.

prinzipell ja. wir verstehen wohl bloß unter unt 'prof.' entwicklung etwas anderes.

Meine Ansciht über 'professionelle' Softwareentwicklung ist eben, daß _ich_ so wsauber wie Möglich arbeite.

naja, ich meinte mehr teamwork und vor allem auch die nutzung von anderen komponenten, modulen, usw.

» weil sie Linux schreiben können, sind sie _die_ Spezialisten.
soll ich mich jetzt kritisiert fühlen?

Leute, die irgendwas zusammendrehen, sollen das auch tun. Sie werdens meist nicht lange tun. Qualität der eigenen Arbeit ist im Endeffekt immer der Garant für weitere Aufträge.

Bis jetzt bin ich noch nicht auf die Idee gekommen, in Perl eine reine Applikation zu schreiben.

das wollte daniel aber glaube.

Es ging ja nicht darum in Perl einen Browser zu schreiben oder eine IDE oder eine Tabellenkalkulation.
Das sollten wir nicht vergessen!

dann hatte ich ihn falsch verstanden.

cu ronny

[klaus]

hallo ronny,

wir eigentlich in den wirklich wesenlichen Punkten ja eh einer Meinung sind.
prinzipell ja. wir verstehen wohl bloß unter unt 'prof.' entwicklung etwas anderes.

ich weiß nicht. Ich denke ich versteh schon, was Du meinst, und kann das auch voll unterschreiben.

Meine Ansciht über 'professionelle' Softwareentwicklung ist eben, daß _ich_ so wsauber wie Möglich arbeite.
naja, ich meinte mehr teamwork und vor allem auch die nutzung von anderen komponenten, modulen, usw.

Geht ja wohl auch unter Perl. siehe CPAN.
Ich arbeite an einer komplexeren Intranet-Lösung, welche ein umfassendes Informationssystem für eine Firma ist. Da werden unterschiedlichste Plattformen (sowohl Server als auch Client) eingesetzt.
Perl ist eigentlich die Sprache, die alles zusammenhält.
Zum einen, weil ich Scripts schreiben kann, welche unter Windows, VMS und Unix ohne Änderungen lauffähig sind.
Dann gibts eben zu Perl soviel für mich interessante Module, welche die Entwicklungszeit erheblich verkürzt haben.
Es gibt zwar einige 'kranke' Lösungen, weil einige Quellsysteme nicht leicht zu erreichen sind. aber mit Perl ist's wenigsten überhaupt möglich.
Die Entwicklung wird von einem kleinen Team von 5 Leuten getragen, wobei auch hier die Teamfähigkeit wesentlich ist.
Module müssen eben einen gewissen Standard einhalten, analog zu den Gegebenheiten in anderen Entwicklungsprojekten.
Auch Programm-Schittstellen sind da recht klar definiert.

Das es da draußen Leute gibt, die Schrott produzieren, ist nicht das Thema. Die haben ebene noch nicht kapiert, wie sies anpacken sollten.
Andererseits, wenns funktioniert, und sie glücklich mit Ihrer Lösung sind, dann ist's ja auch gut. 'Ein Programm, das Läuft, ist ein gutes Programm'.
Ich mach's eben anders, ob besser, daß kann ich nicht sagen. Sich selbst zu beurteilen ist meist so eine Sache.
Ich nehm mir nur nicht das Recht heraus, zu 'wissen' wie _alle_ programmieren sollen.

» weil sie Linux schreiben können, sind sie _die_ Spezialisten.
soll ich mich jetzt kritisiert fühlen?

sicher nicht!

Bis jetzt bin ich noch nicht auf die Idee gekommen, in Perl eine reine Applikation zu schreiben.
das wollte daniel aber glaube.

weiß nicht.

Es ging ja nicht darum in Perl einen Browser zu schreiben oder eine IDE oder eine Tabellenkalkulation.
Das sollten wir nicht vergessen!
dann hatte ich ihn falsch verstanden.

weiß nicht, vielleicht,. daß kann uns glaub ich nur Daniel beantworten.

Grüße
Klaus

[ronny]

hallo klaus,

naja, ich meinte mehr teamwork und vor allem auch die nutzung von anderen komponenten, modulen, usw.
Geht ja wohl auch unter Perl. siehe CPAN.

komm, zwischen cspan und ejb oder jb ist doch wohl ein unterschied. ein echten komponentenmodell bietet perl einfach nicht.

Perl ist eigentlich die Sprache, die alles zusammenhält.
weil ich Scripts schreiben kann, welche unter Windows, VMS und Unix ohne Änderungen lauffähig sind.

java? ich verwende unix und nt. dafür geht es zumindest sehr gut. für webgeschichten ist momentan für mich die kombi der wahl: jsp+servlets+jb (oder ejb). das gibt sehr gute performenz+schnelle entwicklung.

'Ein Programm, das Läuft, ist ein gutes Programm'.

ich hoffe, du meinst das nicht ernst...

Ich nehm mir nur nicht das Recht heraus, zu 'wissen' wie _alle_ programmieren sollen.

das wollte ich auch nicht. aber es gibt doch gewisse allgemeingültige grundsätze über effiziente entwicklung. oder? ob das komponentenmodell echt so viel bringt, wie behauptet, kann man vielleicht anzweifeln, aber zumindest für die entwicklung für web UND applikationen kann doch ziemliche synetherien erzeugen.

» weil sie Linux schreiben können, sind sie _die_ Spezialisten.
soll ich mich jetzt kritisiert fühlen?
sicher nicht!

danke. *g*

mfg,
ronny

[klaus]

hallo ronny,

komm, zwischen cspan und ejb oder jb ist doch wohl ein unterschied. ein echten komponentenmodell bietet perl einfach nicht.

nein, wirklich nicht.

java? ich verwende unix und nt. dafür geht es zumindest sehr gut. für webgeschichten ist momentan für mich die kombi der wahl: jsp+servlets+jb (oder ejb). das gibt sehr gute performenz+schnelle entwicklung.

war damals, als wir begonnen haben eigentlich Müll. Gibts eigentlich Java unter VMS? Egal, inzwishcen haben wir schon soviel Code, der wunderbar funktioniert, daß es sinnlos wäre, nur der 'richtigen' Sprache wegen alles umzukrempeln.
Wir haben inzwischen schon eine recht umfangreiche Modul-Bibliothek, die uns die Arbeit ziemlich erleichtert.

'Ein Programm, das Läuft, ist ein gutes Programm'.
ich hoffe, du meinst das nicht ernst...

Doch, ist zwar akademisch nicht der richtige Ansatz, aber besser ein funktionierendes (!!) Programm, als ein theoretisch richtiges design. ;-)
Nein im Ernst, ein wirklich funktionierendes Programm ist m.E. auch kein schlecht designtes. Und das beste Design kann durch veränderte Rahmenbedingungen obsolet werden.
Du siehst, ich bin ziemlich pragmatisch, was das angeht. 'Wenn's funktioniert, dann denk nicht mehr drüber nach.' Dabei will ich schon auch betonen, daß vorher Überlegungen angestellt werden sollen, wie ein Programm entwickelt wird, daß nicht bei der erst besten Änderung alles gleich beim Teufel ist.
Es ist halt immer eine Frage von Aufwand zu Nutzen, Wertanalyse schon von Beginn weg betreiben bringts wirklich.
Ein Programm, welches per Definition eine Übergangslösung darstellt (das gibts auch), werde ich nicht für alle Eventualitäten auslegen.
Bei der Siemens ist eine Zeit lan einspruch in den Büros herumgegeistert, der schon etwas für sich hat
'Besser die zweitbeste Lösung sofort, als die Beste Lösung nie'
Ist auch ziemlich pragmatisch, find ich.

Und dann gibts noch die Geschichte von einer Meßwerterfassung für Tiefbohrungen, die beim MIT entwickelt werden sollte, nach acht Jahren aber aufgegeben wurde, weil sie nie aus der Designphase gekommen sind (mit 10-20 Mitarbeitern) und eine kleine Quetschn in Österreich hat mit 2 Leuten in einem Jahr 3 Anlagen mit einer funktionierenden Software ausgestattet. Und die haben in VB geschrieben.
So kann auch gehen.

Schönen Abend noch
Klaus

PS.: Ich glaub jetzt haben wir uns aber ganz schön vom Thema entfernt. Vielleicht ist dieses Forum ab sofort niocht mehr der richtige Ort. Aber ich kann mich auch vollkommen irren.

[Kai Diefenbach]

... und Sockets unter Win32 all das machen was man auch mit C++ und Sockets kann oder kann C++ mehr?

Was kann man denn mit C++ so alles machen ?

Und gibt es eine Möglichkeit mit Perl eigene Pakete unter win32 zu erstellen?

Ja klar !

perldoc perlmod

und wenn's OO sein soll

perldoc perlobj
perldoc perltoot

mfg
D.M.

Gruß
   Kai

[Daniel Milson]

Hi,

danke erstmal.

... und Sockets unter Win32 all das machen was man auch mit C++ und Sockets kann oder kann C++ mehr?

Was kann man denn mit C++ so alles machen ?

Naja das was ich unten beschrieben habe :)

Und gibt es eine Möglichkeit mit Perl eigene Pakete unter win32 zu erstellen?

Ja klar !

perldoc perlmod

Hab ich geschaut, aber was meinst du da? Ich finde da nichts über manuelles Erstellen von TCP/IP Paketen etc.

mfg
D.M.

[Kai Diefenbach]

Hallo

Und gibt es eine Möglichkeit mit Perl eigene Pakete unter
win32 zu erstellen?

Ja klar !
perldoc perlmod

Hab ich geschaut, aber was meinst du da? Ich finde da nichts über manuelles Erstellen von TCP/IP Paketen etc.

Sorry, war ein Missverstaendnis, ich dachtem, Du denkst ueber das Erstellen von Paketen (sprich Modulen) unter Perl nach.

mfg
D.M.

Gruss
   Kai