Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #405739 > unrolled thread

C++ nein danke

Back to article view | Back to ger.ct

Contents

  C++ nein danke Hermann Riemann <nospam.ng@hermann-riemann.de> - 2019-07-12 18:18 +0200
    Re: C++ nein danke Lothar Kimmeringer <news201705@kimmeringer.de> - 2019-07-12 23:49 +0200
      Re: C++ nein danke Herwig AQSR <herwig.huener@t-online.de> - 2019-07-12 16:30 -0700
      Re: C++ nein danke Hermann Riemann <nospam.ng@hermann-riemann.de> - 2019-07-13 07:02 +0200
        Re: C++ nein danke Lothar Kimmeringer <news201705@kimmeringer.de> - 2019-07-13 11:39 +0200
    Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-13 18:20 +0200
      Re: C++ nein danke Lothar Kimmeringer <news201705@kimmeringer.de> - 2019-07-13 20:48 +0200
        Re: C++ nein danke Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2019-07-13 21:20 +0000
          Re: C++ nein danke Sebastian Peters <petseb@nymph.paranoici.org> - 2019-07-14 17:21 +0200
            Re: C++ nein danke Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2019-07-14 19:19 +0000
        Re: C++ nein danke Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-07-14 02:01 +0200
        Re: C++ nein danke Hermann Riemann <nospam.ng@hermann-riemann.de> - 2019-07-15 06:52 +0200
          Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-15 11:13 +0200
            Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-16 10:20 +0200
              Re: C++ nein danke Herwig AQSR <herwig.huener@t-online.de> - 2019-07-16 16:08 -0700
              Re: C++ nein danke Herwig AQSR <herwig.huener@t-online.de> - 2019-07-16 16:11 -0700
                Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-17 11:13 +0200
                  Re: C++ nein danke Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-07-17 11:29 +0200
                    Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-17 11:37 +0200
                      Re: C++ nein danke Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-07-17 16:24 +0200
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-17 17:53 +0200
                          Re: C++ nein danke Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-07-17 19:28 +0200
                            Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-17 20:02 +0200
                              Re: C++ nein danke Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2019-07-17 20:44 +0200
                                Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-17 21:16 +0200
                  Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 08:48 +0200
                    Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 16:01 +0200
                    Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 16:02 +0200
                      Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 16:58 +0200
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 17:32 +0200
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 18:16 +0200
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 18:17 +0200
                        Re: C++ nein danke Hans im Glück <hig68@gmx.at> - 2019-07-18 18:27 +0200
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 19:15 +0200
                          Re: C++ nein danke "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-07-19 06:54 +0000
                            Re: C++ nein danke "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-07-19 06:59 +0000
                        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-18 20:27 +0200
                          Re: C++ nein danke Sepp Neuper <Sepp_Neuper@web.de> - 2019-07-19 03:15 +0200
                            Re: C++ nein danke Wolfgang Kynast <wky@gmx.de> - 2019-07-19 09:07 +0200
                            Re: C++ nein danke Lars Gebauer <lars.gebauer@yahoo.de> - 2019-07-19 07:34 +0000
                        Re: C++ nein danke "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-07-19 06:35 +0000
                    Re: C++ nein danke Herwig AQSR <herwig.huener@t-online.de> - 2019-07-19 03:59 -0700
                      Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-19 13:06 +0200
                        Re: C++ nein danke Herwig AQSR <herwig.huener@t-online.de> - 2019-07-19 14:43 -0700
                          Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-20 09:12 +0200
      Re: C++ nein danke Hermann Riemann <nospam.ng@hermann-riemann.de> - 2019-07-15 07:03 +0200
        Re: C++ nein danke "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2019-07-15 08:32 +0000
          Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-16 10:18 +0200
        Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-15 11:09 +0200
          Re: C++ nein danke Bonita Montero <Bonita.Montero@gmail.com> - 2019-07-16 10:24 +0200

Page 1 of 3  [1] 2 3  Next page →

#405739 — C++ nein danke

Ich habe vor kurzen mal wieder ein wenig C++ gelesen.

Wenn ich da C++ mit Python vergleiche:

C++ ( Handbuch Wolf Seite 145)

std::string str01("eine Textfolge")
std::cout << "3.Buchstabe: " << str01.at(2) << std::endl;
std::cout << "Letzter Buchstabe: " << str01.bak() << atd::end1

in Python3  würde das so aussehen:

str03="eine Textfolge"
print("3.Buchstabe: "+str01[2])
print("Letzter Buchstabe: "+str01[-1])

( statt blank"+ könnte auch ", stehen.
   allerdings nicht bei write)

Da erscheint mir C++ als Mittelding
zwischen Python und COBOL.

Und das << finde ich auch etwas verwirrend
std::endl wird doch nicht in str* geschoben.

Hermann
    der bei strings auch kein str01.begin()
    und str01.bend() verwenden mag.

-- 
http://www.hermann-riemann.de

[toc] | [next] | [standalone]

#405754

Hermann Riemann wrote:

> C++ ( Handbuch Wolf Seite 145)
> 
> std::string str01("eine Textfolge")
> std::cout << "3.Buchstabe: " << str01.at(2) << std::endl;
> std::cout << "Letzter Buchstabe: " << str01.bak() << atd::end1
> 
> in Python3  würde das so aussehen:
> 
> str03="eine Textfolge"
> print("3.Buchstabe: "+str01[2])
> print("Letzter Buchstabe: "+str01[-1])

Gross unterschiedlich ist das nicht und Python wird z.B. dann
unuebsichtlicher, wenn du z.B. keinen Zeilenumbruch willst:

In C++
std::cout << "3.Buchstabe: ";
std::cout << str01.at(2);

In Python:

print("3.Buchstabe: ", end = "")
print(str01.at(2)), end = "")

> ( statt blank"+ könnte auch ", stehen.
>    allerdings nicht bei write)
> 
> Da erscheint mir C++ als Mittelding
> zwischen Python und COBOL.

Bei dem Beispiel sehe ich ehrlich gesagt keinen
sonderlich grossen Unterschied und COBOL ist wohl
eine ganz andere Liga an Lesbarkeit.

> Und das << finde ich auch etwas verwirrend
> std::endl wird doch nicht in str* geschoben.

Nein. Aber in cout, nachdem str01.at(2) reingeschoben
wurde, nachdem "3.Buchstabe: " reingeschoben wurde.


Gruesse, Lothar
-- 
Lothar Kimmeringer                E-Mail: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

[toc] | [prev] | [next] | [standalone]

#405763

2019-07-13 01:30:00 +0200

> ...

> Bei dem Beispiel sehe ich ehrlich gesagt keinen
> sonderlich grossen Unterschied und COBOL ist wohl
> eine ganz andere Liga an Lesbarkeit.

COBOL hat eine sehr gute Lesbarkeit - wenn ich in
einem Posting das Wort "COBOL" lese, gehe ich auf
die Toilette, erbreche mich, und mache dann mit
einem anderen Thread weiter.

Herwig

[toc] | [prev] | [next] | [standalone]

#405766

Am 12.07.19 um 23:49 schrieb Lothar Kimmeringer:

> Gross unterschiedlich ist das nicht und Python wird z.B. dann
> unuebsichtlicher, wenn du z.B. keinen Zeilenumbruch willst:

> In C++
> std::cout << "3.Buchstabe: ";
> std::cout << str01.at(2);

> In Python:

> print("3.Buchstabe: ", end = "")
> print(str01.at(2)), end = "")

print(end="3.Buchstabe: ")
..

> Bei dem Beispiel sehe ich ehrlich gesagt keinen
> sonderlich grossen Unterschied und COBOL ist wohl
> eine ganz andere Liga an Lesbarkeit.

COBOL ist für mich ein Extrembeispiel von Geschwätzigkeit,
wo man vor lauter Text den Ablauf nur zäh wiederfindet.

Bei der Wahl, ob ich ein Formular mit COBOL (PICTURE)
oder eine html-Datei mit Python nachbearbeite
ziehe ich nicht nur theoretisch das Letztere vor.

>> Und das << finde ich auch etwas verwirrend
>> std::endl wird doch nicht in str* geschoben.
> 
> Nein. Aber in cout, nachdem str01.at(2) reingeschoben
> wurde, nachdem "3.Buchstabe: " reingeschoben wurde.

Bei mir beisst sich das mit der Unix pipe
Kommandoergebnis > Datei ( stdout ist auch Datei)

Hermann
    dessen COBOL Erfahrung reichte,
    um diese Sprache zu vermeiden.
    Und an vielen Tagen Texte per Python bearbeitet.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#405799

Hermann Riemann wrote:

> Am 12.07.19 um 23:49 schrieb Lothar Kimmeringer:
> 
>> print("3.Buchstabe: ", end = "")
> 
> print(end="3.Buchstabe: ")

Das ist nicht wirklich lesbarer. Im Prinzip laeuft
es aber auf Geschmack und Gewohnheit hinaus.

>>> Und das << finde ich auch etwas verwirrend
>>> std::endl wird doch nicht in str* geschoben.
>> 
>> Nein. Aber in cout, nachdem str01.at(2) reingeschoben
>> wurde, nachdem "3.Buchstabe: " reingeschoben wurde.
> 
> Bei mir beisst sich das mit der Unix pipe
> Kommandoergebnis > Datei ( stdout ist auch Datei)

Lustig, dass du Shellprogrammierung erwaehnst. Da gibt
es das auch.

echo <<EOTEXT
Dies
ist ein
mehrzeiliger Text
EOTEXT


Gruesse, Lothar
-- 
Lothar Kimmeringer                E-Mail: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

[toc] | [prev] | [next] | [standalone]

#405876

C++ und Python sind keine Alternativen füt den selben Einsatz-Zweck,
insofern ist der Vergleich idiotisch.
C++ ist halt ein guter Mittelweg zwischen Abstraktion und Performance.
In dem Verhältnis wie bei C++ gibt es das bei keiner anderen Sprache;
selbst Rust kann C++ bzgl. der Performance meist ncht das Wasser rei-
chen.
Python ist halt ne Scriptsprache mit viel Convenience und dementsprech-
end langsam. Außerdem ist es auch aufgrund der nicht vorhandenen Sysem
-nähe für einen anderen Anwendungs-Bereich ausgelegt.

[toc] | [prev] | [next] | [standalone]

#405907

Bonita Montero wrote:

> selbst Rust kann C++ bzgl. der Performance meist ncht das Wasser rei-
> chen.

Da waere aber mal interessant, warum das so ist, wenn OpenSSL
in C gegenueber rustls in Rust so dermassen abkackt:
https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html

    rustls is 15% quicker to send data.
    rustls is 5% quicker to receive data.
    rustls is 20-40% quicker to set up a client connection.
    rustls is 10% quicker to set up a server connection.
    rustls is 30-70% quicker to resume a client connection.
    rustls is 10-20% quicker to resume a server connection.
    rustls uses less than half the memory of OpenSSL.


Gruesse, Lothar
-- 
Lothar Kimmeringer                E-Mail: spamfang@kimmeringer.de
               PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
                 questions!

[toc] | [prev] | [next] | [standalone]

#405937

On Sat, 13 Jul 2019 20:48:30 Lothar Kimmeringer wrote:
> Bonita Montero wrote:
> > selbst Rust kann C++ bzgl. der Performance meist ncht das Wasser
> > reichen.
 
> Da waere aber mal interessant, warum das so ist, wenn OpenSSL
> in C gegenueber rustls in Rust so dermassen abkackt:
> https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html
 
Ohne auch nur den Funken eine Ahnung von einer der beiden
Implementierungen zu haben würde ich das als den entscheidenden
Hinweis betrachten:

>     rustls uses less than half the memory of OpenSSL.

Der Speicherverbrauch sollte sich nicht *so* stark unterscheiden,
also ist wahrscheinlich - aus welchen Gründen auch immer, z.B. wegen
Altlasten - einfach die Implementierung von OpenSSL schlechter.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Stefan: die süße Verführung!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#406083

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) schrieb:
>On Sat, 13 Jul 2019 20:48:30 Lothar Kimmeringer wrote:
>> Bonita Montero wrote:
>> > selbst Rust kann C++ bzgl. der Performance meist ncht das Wasser
>> > reichen.
> 
>> Da waere aber mal interessant, warum das so ist, wenn OpenSSL
>> in C gegenueber rustls in Rust so dermassen abkackt:
>> https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html
> 
>Ohne auch nur den Funken eine Ahnung von einer der beiden
>Implementierungen zu haben würde ich das als den entscheidenden
>Hinweis betrachten:
>
>>     rustls uses less than half the memory of OpenSSL.
>
>Der Speicherverbrauch sollte sich nicht *so* stark unterscheiden,
>also ist wahrscheinlich - aus welchen Gründen auch immer, z.B. wegen
>Altlasten - einfach die Implementierung von OpenSSL schlechter.

Vielmehr scheint die Implementierung in rustls alles andere als
komplett, wie beispielsweise in
<https://dzone.com/articles/using-tls-with-rust-part-1> beschrieben.

| I have no clue why this is failing. According to the docs, this is
| supposed to work.
[...]
| Go back a bit and see what kind of URL I gave to OpenSSL; it was
| 127.0.0.1, and it seems like rustls doesn’t support raw IPs, only
| hostnames.
[...]
| This seems to be a known error that has been opened since May 2017,
| and it is a complete deal breaker for me.

Demgegenüber machen komplexere Entscheidungsbäume Programme grösser,
langsamer, aber nicht notwendigerweise schlechter.

Grüsse

[toc] | [prev] | [next] | [standalone]

#406115

On Sun, 14 Jul 2019 17:21:26 Sebastian Peters wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) schrieb:
> >Ohne auch nur den Funken eine Ahnung von einer der beiden
> >Implementierungen zu haben würde ich das als den entscheidenden
> >Hinweis betrachten:

> >>     rustls uses less than half the memory of OpenSSL.

> >Der Speicherverbrauch sollte sich nicht *so* stark unterscheiden,
> >also ist wahrscheinlich - aus welchen Gründen auch immer, z.B.
> >wegen Altlasten - einfach die Implementierung von OpenSSL
> >schlechter.
> 
> Vielmehr scheint die Implementierung in rustls alles andere als
> komplett, wie beispielsweise in
> <https://dzone.com/articles/using-tls-with-rust-part-1> beschrieben.
> 
> | it seems like rustls doesn’t support raw IPs, only  hostnames.

Oh.

So kann man natürlich auch Speicher sparen (und ggf. Performance
gewinnen), aber wirklich einladend klingt das nicht gerade.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Vergnügen mit Stefan, verbissen und horrend!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#405942

Am 13.07.19 um 20:48 schrieb Lothar Kimmeringer:

> Da waere aber mal interessant, warum das so ist, wenn OpenSSL
> in C gegenueber rustls in Rust so dermassen abkackt:

OpenSSL ist mehr als 20 Jahre alt und hat sämtliche historischen 
SSL-Generationen durchlebt. Da dürften unzählige Leichen als Ballast im 
Code schlummern.

Hergen

[toc] | [prev] | [next] | [standalone]

#406146

Am 13.07.19 um 20:48 schrieb Lothar Kimmeringer:

> Da waere aber mal interessant, warum das so ist, wenn OpenSSL
> in C gegenueber rustls in Rust so dermassen abkackt:
> https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html

>      rustls is 15% quicker to send data.
>      rustls is 5% quicker to receive data.
>      rustls is 20-40% quicker to set up a client connection.
>      rustls is 10% quicker to set up a server connection.
>      rustls is 30-70% quicker to resume a client connection.
>      rustls is 10-20% quicker to resume a server connection.
>      rustls uses less than half the memory of OpenSSL.

Da klingt für mich nach einigen optimierten IO Systembibliotheken.
Auf anderen Gebieten wie Verkettungen mag es anders aussehen.

Hermann
    der keine für ihn nützliche Anwendung kennt,
    für den rust gegenüber Python ( einfache Programmierung)
    oder C ( spezielle Arithmetiken ) besser wäre.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#406208

> Da klingt für mich nach einigen optimierten IO Systembibliotheken.
> Auf anderen Gebieten wie Verkettungen mag es anders aussehen.

Jaja, die Krux der Verkettungen in Rust; jeder weiß davon!!!11 ;-)

> Hermann
>     der keine für ihn nützliche Anwendung kennt,
>     für den rust gegenüber Python ( einfache Programmierung)
>     oder C ( spezielle Arithmetiken ) besser wäre.

C ist ne altertümliche Sprache die eine Menge Programmier-Aufwand
selbst für einfachste Aufgaben erfordert. Sowas will man heute ncht
mehr haben. Und Scriptsprachen sind halt für andere Anwwendungs-Zwecke.

[toc] | [prev] | [next] | [standalone]

#406425

>> C ist ne altertümliche Sprache die eine Menge Programmier-Aufwand
>> selbst für einfachste Aufgaben erfordert.

> Ich glaube nicht, dass z.B. Pixelmanipulation
> ( Pointer auf Pixelfeld; bekannt Breite und Höhe; IO über SDL(2))
> in einer anderen Sprache wesentlich besser geht als in C.

Mein Gott, Du bist aber auch uneinsichtig doof. Ich meine, dass manches
simple eben auch einfach geht ist ja noch lange kein Grund dagegen, dass
die Sprache ansich viel manuelles Handwerk erfordert.

>> So etwas will man heute nicht mehr haben.

> Es kann Differenzen geben, zwischen dem, was man gerne hätte,
> und dem was zweckmäßig ist.

Was für ein Geschwurbel. In deinem Sinne ist C eben heute selten
zweckmäßig weil es ziemlich aufwendig ist, damit zu programmieren.

>> Und Scriptsprachen sind halt für andere Anwendungs-Zwecke.

> Es gibt Überschneidungen.

Kaum.

> Hermann
>     der ca 90% von dem, was er vor ca 10 Jahren mit C erledigt hat,
>     heute mit Python erledigt.

Als hätte es damals nicht schon brauchbare Scriptsprachen gegeben.

>     und nicht ein einziges in C++ selbstgeschriebenes Programm
>     verwendete.

Was der Bauer nicht kennt, das frisst er nichzt.

[toc] | [prev] | [next] | [standalone]

#406566

2019-07-17 01:09:00 +0200

> ...

> Mein Gott, Du bist aber auch uneinsichtig doof.

Wir hatten mal einen HauptAbteilungsLeiter, der dazu
angehalten wurde, eine Ausarbeitung zu schreiben,
die darlegt, warum ihn keiner mag. Sowas geht im
Usenet nicht so richtig.

Herwig

[toc] | [prev] | [next] | [standalone]

#406567

2019-07-17 01:12:00 +0200

> ...

> >> Und Scriptsprachen sind halt für andere Anwendungs-Zwecke.
> 
> > Es gibt Überschneidungen.
> 
> Kaum.

Doch.

Herwig

[toc] | [prev] | [next] | [standalone]

#406607

>>>> Und Scriptsprachen sind halt für andere Anwendungs-Zwecke.

>>> Es gibt Überschneidungen.

>> Kaum.

> Doch.

Es geht nicht un mögliche Kann-Überschneidungen, sondern die Sollte
Überschneidungen. Und wenn man die Performance oder System-Nähe von
C/C++ nicht braucht dann ist man schon so gut bei nicht systemnahen
Sprachen wie Scriptsprachen oder VM-SPrachen. Da gibt es also eine
fast scharfe Trennlinie, zumindest wenn man es leidenschaftslos
sieht.

[toc] | [prev] | [next] | [standalone]

#406609

Am 17.07.19 um 11:13 schrieb Bonita Montero:

> Es geht nicht un mögliche Kann-Überschneidungen, sondern die Sollte
> Überschneidungen. Und wenn man die Performance oder System-Nähe von
> C/C++ nicht braucht dann ist man schon so gut bei nicht systemnahen
> Sprachen wie Scriptsprachen oder VM-SPrachen. Da gibt es also eine
> fast scharfe Trennlinie, zumindest wenn man es leidenschaftslos
> sieht.

Es gibt da auch noch einen weiteren Faktor, der die Trennlinie wieder 
verwischt: Die Nachhaltigkeit.

C++ und mehr noch C sind schon Jahrzehnte auf dem Markt und werden sich 
noch etliche weitere Jahrzehnte halten, schon weil sie für die System- 
und Embedded-Programmierung unverzichtbar sind. Du wirst auch in 20 
Jahren noch Entwickler finden, die dein in C geschriebenes Produkt 
warten können.

Bei etlichen der derzeit angesagten Modesprachen kann sich das Blatt 
dagegen sehr schnell wieder wenden. Das gilt besonders für Sprachen, die 
letztlich am Engagement einer einzelnen Firma hängen.

[toc] | [prev] | [next] | [standalone]

#406611

> C++ und mehr noch C sind schon Jahrzehnte auf dem Markt und werden sich 
> noch etliche weitere Jahrzehnte halten, schon weil sie für die System- 
> und Embedded-Programmierung unverzichtbar sind. Du wirst auch in 20 
> Jahren noch Entwickler finden, die dein in C geschriebenes Produkt 
> warten können.

Mag sein, aber wenn wir von bekannten Scriptsprachen und nicht irgend-
welchen Sternschnuppen spricht die sowieso kaum einer nutzt, dann gibts
da kaum eine Unschärfe. Selbst Ruby war nie so populär, dass man es als
verbreitet hat nennen können.

> Bei etlichen der derzeit angesagten Modesprachen kann sich das Blatt 
> dagegen sehr schnell wieder wenden. Das gilt besonders für Sprachen,
> die  letztlich am Engagement einer einzelnen Firma hängen.

Welche denn?

[toc] | [prev] | [next] | [standalone]

#406658

Am 17.07.19 um 11:37 schrieb Bonita Montero:

>> Bei etlichen der derzeit angesagten Modesprachen kann sich das Blatt 
>> dagegen sehr schnell wieder wenden. Das gilt besonders für Sprachen,
>> die  letztlich am Engagement einer einzelnen Firma hängen.
> 
> Welche denn?

Da wäre an vorderster Front erst mal C#, das derzeit sämtliche 
Stellenanzeigen dominiert. Wir müssen ja für Marktführer programmieren, 
und der Marktführer empfiehlt das, also setzen wir das mal vorab für 
alle Neueinstellungen. Sollte MS morgen verkünden, das C# out und fortan 
D## angesagt ist, wirst du in ein paar Jahren mit der Lupe nach Leuten 
suchen können, die sich den nicht mehr supporteten, proprietäten Krempel 
noch antun wollen.

Dann denke ich an Sachen wir Rust oder Go, die letztlich auch an der 
Gunst einer einzelnen Compiler-Quelle hängen. Wenn die nicht mehr 
liefert oder was Besseres nachlegt...

Bei den Scriptsprachen könnte man Python nennen. Derzeit enorm populär. 
Aber das war Perl auch mal, bis es Besseres gab. Finde heute mal 
jemanden, der richtig gut Perl kann...

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | ger.ct

csiph-web