Python, Perl und PHP

[titrat]

Die "Three dangerours P" sollen eine sichere Wahl sein?
Oder gar C und C++, DIE Programmiersprachen für Buffer-Overflows?

Im Gegensatz zu Java oder C#?
Also lieber löchrige Programme anstatt nachvollziehbare, pflegbare Anwendungen?
Eine hypotethische Gefahr eines Paranoiden gegenüber realen Risiken, die täglich Brot sind?
Ich weiß, was ich da wähle.

[fratzenbuch]

titrat schrieb:
--------------------------------------------------------------------------------
> ...
> Ich weiß, was ich da wähle.
ORACLE?
da hab ich mein täglich brot bei facebook oder eben golem.de mit gepflegtem php lieber!

[Anus]

Ich sach nur Python.

[Dadie]

titrat schrieb:
--------------------------------------------------------------------------------
> Die "Three dangerours P" sollen eine sichere Wahl sein?
> Oder gar C und C++, DIE Programmiersprachen für Buffer-Overflows?
>
> Im Gegensatz zu Java oder C#?
> Also lieber löchrige Programme anstatt nachvollziehbare, pflegbare
> Anwendungen?
> Eine hypotethische Gefahr eines Paranoiden gegenüber realen Risiken, die
> täglich Brot sind?
> Ich weiß, was ich da wähle.

Einen Buffer-Overflow kann ich sowohl bei C als auch bei C++ durch einen guten Programmcode verhindern. Java Programmierer sind aber von der VM abhängig und müssen hoffen und betten dass die VM dann doch bitte keine Sicherheitslücke besitzt. Da Schreib ich lieber mein C++ und weiß woran ich bin. Wenn was schief läuft weiß ich "Mein Code war scheiße" und muss nicht erst mit einigen VM-Versionen herum testen ob es nicht dann doch an der VM liegt.

[GodsBoss]

> > Die "Three dangerours P" sollen eine sichere Wahl sein?
> > Oder gar C und C++, DIE Programmiersprachen für Buffer-Overflows?
> >
> > Im Gegensatz zu Java oder C#?
> > Also lieber löchrige Programme anstatt nachvollziehbare, pflegbare
> > Anwendungen?
> > Eine hypotethische Gefahr eines Paranoiden gegenüber realen Risiken, die
> > täglich Brot sind?
> > Ich weiß, was ich da wähle.
>
> Einen Buffer-Overflow kann ich sowohl bei C als auch bei C++ durch einen
> guten Programmcode verhindern. Java Programmierer sind aber von der VM
> abhängig und müssen hoffen und betten dass die VM dann doch bitte keine
> Sicherheitslücke besitzt. Da Schreib ich lieber mein C++ und weiß woran ich
> bin. Wenn was schief läuft weiß ich "Mein Code war scheiße" und muss nicht
> erst mit einigen VM-Versionen herum testen ob es nicht dann doch an der VM
> liegt.

Und dann war es doch ein Bug im C++-Compiler.

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[GodsBoss]

Wieso sollen Python, Perl und PHP die „Three dangerous P“ sein?

Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.

[Dadie]

GodsBoss schrieb:
--------------------------------------------------------------------------------
> > > Die "Three dangerours P" sollen eine sichere Wahl sein?
> > > Oder gar C und C++, DIE Programmiersprachen für Buffer-Overflows?
> > >
> > > Im Gegensatz zu Java oder C#?
> > > Also lieber löchrige Programme anstatt nachvollziehbare, pflegbare
> > > Anwendungen?
> > > Eine hypotethische Gefahr eines Paranoiden gegenüber realen Risiken,
> die
> > > täglich Brot sind?
> > > Ich weiß, was ich da wähle.
> >
> > Einen Buffer-Overflow kann ich sowohl bei C als auch bei C++ durch einen
> > guten Programmcode verhindern. Java Programmierer sind aber von der VM
> > abhängig und müssen hoffen und betten dass die VM dann doch bitte keine
> > Sicherheitslücke besitzt. Da Schreib ich lieber mein C++ und weiß woran
> ich
> > bin. Wenn was schief läuft weiß ich "Mein Code war scheiße" und muss
> nicht
> > erst mit einigen VM-Versionen herum testen ob es nicht dann doch an der
> VM
> > liegt.
>
> Und dann war es doch ein Bug im C++-Compiler.

Zum Glück wird Java nicht compiliert sondern nur in Java-Bitcode umgewandelt. Was ja allgemein etwas vollkommen anderes darstellt. Selbiges Problem mit dem Compiler trifft auf Java ebenfalls zu. Und nun?

[DinoDino]

Dadie schrieb:
--------------------------------------------------------------------------------
> titrat schrieb:
> ---------------------------------------------------------------------------
> -----
> > Die "Three dangerours P" sollen eine sichere Wahl sein?
> > Oder gar C und C++, DIE Programmiersprachen für Buffer-Overflows?
> >
> > Im Gegensatz zu Java oder C#?
> > Also lieber löchrige Programme anstatt nachvollziehbare, pflegbare
> > Anwendungen?
> > Eine hypotethische Gefahr eines Paranoiden gegenüber realen Risiken, die
> > täglich Brot sind?
> > Ich weiß, was ich da wähle.
>
> Einen Buffer-Overflow kann ich sowohl bei C als auch bei C++ durch einen
> guten Programmcode verhindern. Java Programmierer sind aber von der VM
> abhängig und müssen hoffen und betten dass die VM dann doch bitte keine
> Sicherheitslücke besitzt. Da Schreib ich lieber mein C++ und weiß woran ich
> bin. Wenn was schief läuft weiß ich "Mein Code war scheiße" und muss nicht
> erst mit einigen VM-Versionen herum testen ob es nicht dann doch an der VM
> liegt.

Ja ja durch guten Code. Das kommt mir nur all zu bekannt vor. Besonders weil ich mir das von allen möglichen Profs anhören musste und mir dann später anhören muss wenn man einen Fehler drin hat wie schwierig es ist diesen tatsächlich zu finden. Und an dem tag an dem es fehlerfreiencode wirklich gibt wird sowieso die welt untergehen. Aber auch sonst gestaltet sich die fehlersuche bei java im vergleich zu c++ wesentlich einfacher. Da ist es dann egal wer denn fehler gemacht hat, weil es wesentlich wichtiger den fehler zu beseitigen.

[dummbacke]

mit deinem java kriegst du nie so präzise arbeitende software hin, wie mit c/c++. Das ist nunmal nicht das, wofür java geschaffen wurde. java soll eine vergleichsweise einfache, platformübergreifende lösung sein, dank der durch die laufzeitumgebung für jeweilige betriebssysteme immer gleichen "API". Mit einfache lösung will ich das nicht auf das level einer scriptsprache runterdrücken, aber es ist halt nicht so hardwarenah und es gibt deswegen auch nicht so viele fatale rückschläge, wenn man schlampt.

[DinoDino]

dummbacke schrieb:
--------------------------------------------------------------------------------
> mit deinem java kriegst du nie so präzise arbeitende software hin, wie mit
> c/c++. Das ist nunmal nicht das, wofür java geschaffen wurde. java soll
> eine vergleichsweise einfache, platformübergreifende lösung sein, dank der
> durch die laufzeitumgebung für jeweilige betriebssysteme immer gleichen
> "API". Mit einfache lösung will ich das nicht auf das level einer
> scriptsprache runterdrücken, aber es ist halt nicht so hardwarenah und es
> gibt deswegen auch nicht so viele fatale rückschläge, wenn man schlampt.


Da hat wohl jemand das letzte mal in den 90 was über java gelesen. Und was ist denn bitte "präzise arbeitende software"? Ja wobei bei Java ist ja bestimmt 2 + 2 so ungefähr 4.

[dummbacke]

ein nup, der mit einer tatsache nicht klarkommt. tut mir für dich leid, dass du so einer bist, auch wenn du das nicht verstehst.

[nudelsalat]

dummbacke schrieb:
--------------------------------------------------------------------------------
> mit deinem java kriegst du nie so präzise arbeitende software hin, wie mit
> c/c++. Das ist nunmal nicht das, wofür java geschaffen wurde ...

Was meinst du mit "präzise"?

In den meisten Fällen braucht man überhaupt keine "präzise" arbeitende bzw. hardwarenahe Software.

Und wenn doch, dann wäge ich ab, ob Assembler nicht doch die bessere Wahl ist.

Besonders wenn man Mikrocontroller programmiert ist die "Präzision" von C ein Graus.

Und wenn ich, wie in den meisten Fällen meiner Tätigkeit, gar keine sog. "Präzision" brauche, nehme ich Java, weil die Entwicklung wesentlich eleganter ist, als in C++.

Ich arbeite übrigens auch gerne mit Python ...

Man muss einfach immer das wählen, was für den jeweiligen Einsatzzweck am sinnvollsten ist.

Jemand der sagt, dass A super und B doof ist, hat einfach keine Ahnung oder eine sehr einseitige Arbeit. :)

[DinoDino]

dummbacke schrieb:
--------------------------------------------------------------------------------
> ein nup, der mit einer tatsache nicht klarkommt. tut mir für dich leid,
> dass du so einer bist, auch wenn du das nicht verstehst.

Du solltest dir wohl selbst am meisten leid tun. DU KENNER.

[vitar]

Dadie schrieb:
--------------------------------------------------------------------------------
> Einen Buffer-Overflow kann ich sowohl bei C als auch bei C++ durch einen
> guten Programmcode verhindern.

Es ist in jeder Industrie gängige Praxis, häufig vorkommende Aufgaben zu automatisieren. Nicht nur spart man damit Zeit, es ist letztlich auch deutlich weniger fehleranfällig, wenn man es mit *realer* menschlicher Leistung (nicht etwa einem perfekten, fehlerfrei arbeitenden Menschen) vergleicht.

Speicherverwaltung und die Vermeidung der gängigen Sicherheitslücken in C/C++-Programmen sind solche häufig vorkommenden Aufgaben. Die Automatisierung erfolgt durch Sprachen bzw. Plattformen mit höherem Abstraktionsniveau - etwa Java.

[logie]

> Die "Three dangerours P"

Hier Posten nurnoch Kinder ohne Sachverstand.

Python ist frei.
http://de.wikipedia.org/wiki/Python_%28Programmiersprache%29

Python ist mit C die portabelste Sprache. Selbst auf AMIGAOS läuft noch Python, oder BEOS/HAIKU. Jedes LINUX/UNIX/BSD hat python. Sogar für OS/2 gibt es python. Es gibt mehrere Implementierungen, die schnelste ist Cpython. (importierbare Python Module, welche in C geschrieben und extrem schnell sind.)

[StabiloBoss]

GodsBoss schrieb:
--------------------------------------------------------------------------------
> Wieso sollen Python, Perl und PHP die „Three dangerous P“ sein?


yepp, würde mich auch interessieren.

[cpp kann alles]

vitar schrieb:
--------------------------------------------------------------------------------
>
> Es ist in jeder Industrie gängige Praxis, häufig vorkommende Aufgaben zu
> automatisieren. Nicht nur spart man damit Zeit, es ist letztlich auch
> deutlich weniger fehleranfällig, wenn man es mit *realer* menschlicher
> Leistung (nicht etwa einem perfekten, fehlerfrei arbeitenden Menschen)
> vergleicht.
>
> Speicherverwaltung und die Vermeidung der gängigen Sicherheitslücken in
> C/C++-Programmen sind solche häufig vorkommenden Aufgaben. Die
> Automatisierung erfolgt durch Sprachen bzw. Plattformen mit höherem
> Abstraktionsniveau - etwa ...

http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/smart_ptr.htm
http://www.boost.org/doc/libs/1_44_0/libs/smart_ptr/shared_ptr.htm
http://en.wikipedia.org/wiki/Auto_ptr

[Gastredner]

cpp kann alles schrieb:
> www.boost.org
> www.boost.org
> en.wikipedia.org

Der dadie-Logik folgend dürfte er diese aber nicht einsetzen - die hat er ja nicht selbst entwickelt, ist dabei aber von der korrekten Funktionalität abhängig - er müsste also "hoffen und beten", dass Boost keine Sicherheitslücke besitzt. Genau wie die Java- und C#-Programmierer bei ihrer VM.
Seinen Ausführungen nach ja wohl ein unhaltbarer Zustand.;)

[asda]

Japp, was fürn BS.

Es ist ja schön, dass es auch Programmiersprachen ohne GC gibt, aber das sollte doch inzwischen mehr unter "Historie der Programmiersprachen" und nicht im realen Prxiseinsatz ausgelebt werden.

Es ist nunmal einfach sicherer die JVM abgedichtet zu bekommen als jedes einzelne existierende C/C++-Programm.

[hendryk]

"Three dangerous P" ergibt bei google genau einen treffer....im golem forum.
haste dir ja was schönes ausgedacht