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

Groups > ger.ct > #636235 > unrolled thread

COBOL ersetzen.

Back to article view | Back to ger.ct

Contents

  COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-30 19:45 +0200
    Re: COBOL ersetzen. Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-30 18:08 +0000
      Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-30 20:12 +0200
        Re: COBOL ersetzen. Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-31 12:35 +0000
          Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-31 15:34 +0200
            Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-31 17:12 +0200
          Re: COBOL ersetzen. Michael Bode <m.g.bode@web.de> - 2025-03-31 19:08 +0200
      Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-30 20:22 +0200
    Re: COBOL ersetzen. Marco Moock <mm+solani@dorfdsl.de> - 2025-03-30 20:25 +0200
      Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-30 21:17 +0200
        Re: COBOL ersetzen. Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2025-03-31 07:01 +0000
          Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-31 15:32 +0200
            Re: COBOL ersetzen. Ulf_Kutzner <Ulf.Kutzner@web.de> - 2025-04-22 15:47 +0000
              Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-04-22 22:32 +0200
      Re: COBOL ersetzen. Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-03-31 12:30 +0000
        Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-31 15:39 +0200
          Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-31 17:17 +0200
            Re: COBOL ersetzen. Michael Bode <m.g.bode@web.de> - 2025-03-31 19:08 +0200
          Re: COBOL ersetzen. Marco Moock <mm+solani@dorfdsl.de> - 2025-03-31 17:52 +0200
            Re: COBOL ersetzen. Michael Bode <m.g.bode@web.de> - 2025-03-31 19:13 +0200
        Re: COBOL ersetzen. Marco Moock <mm+solani@dorfdsl.de> - 2025-03-31 17:56 +0200
          Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-03-31 23:17 +0200
          Re: COBOL ersetzen. Martin Ebert <mx300@gmx.net> - 2025-03-31 23:20 +0200
            Re: COBOL ersetzen. Goetz Schultz <ng.expire1225@goetz.co.uk> - 2025-04-01 09:19 +0100
              Re: COBOL ersetzen. Martin Ebert <mx300@gmx.net> - 2025-04-05 02:40 +0200
            Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-01 14:47 +0200
              Re: COBOL ersetzen. Martin Ebert <mx300@gmx.net> - 2025-04-05 02:51 +0200
                Re: COBOL ersetzen. Dietz Proepper <dietz.usenet@rotfl.franken.de> - 2025-04-05 12:20 +0200
                Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-05 13:17 +0200
                  Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-04-07 14:16 +0200
                    Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-07 15:47 +0200
                      Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-04-07 16:12 +0200
                        Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-04-07 17:48 +0200
                          Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-04-07 18:03 +0200
                            Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-07 18:21 +0200
                          Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-07 18:20 +0200
                        Re: COBOL ersetzen. Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-07 18:19 +0200
          Re: COBOL ersetzen. Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2025-04-01 09:21 +0000
            Re: COBOL ersetzen. Ulf Kutzner <user2991@newsgrouper.org.invalid> - 2025-04-01 10:16 +0000
    Re: COBOL ersetzen. Goetz Schultz <ng.expire1225@goetz.co.uk> - 2025-03-31 16:54 +0100
      Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-03-31 18:32 +0200
        Re: COBOL ersetzen. Goetz Schultz <ng.expire1225@goetz.co.uk> - 2025-03-31 17:52 +0100
          Re: COBOL ersetzen. "F. W." <me@home.invalid> - 2025-04-01 12:58 +0200
            Re: COBOL ersetzen. Gerhard Hoffmann <dk4xp@arcor.de> - 2025-04-01 13:51 +0200
              Re: COBOL ersetzen. "F. W." <me@home.invalid> - 2025-04-01 14:47 +0200
    Re: COBOL ersetzen. Georg Gruber <g.gruber_hauwech@gmx.net> - 2025-04-01 21:28 +0200
    Re: COBOL ersetzen. Walter Brill <WalterBrill@t-online.de> - 2025-04-02 14:38 +0200
      Re: COBOL ersetzen. "Dr. Joachim Neudert" <neudert@5sl.org> - 2025-04-02 15:02 +0200
        OK, Danke! (was:Re: COBOL ersetzen.) Walter Brill <WalterBrill@t-online.de> - 2025-04-03 18:54 +0200
      Re: COBOL ersetzen. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2025-04-02 16:45 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#636262

Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:

> On Sun, 30 Mar 2025 20:25:12 Marco Moock wrote:
> > Am 30.03.2025 19:45 Uhr schrieb Hermann Riemann:  
> >> Die US-Behörde für Bürokratieabbau will eine elementare
> >> Programmiersprache in kürzester Zeit ersetzen.  
> 
> >> Was denkt Ihr darüber?  
> 
> > Wird in der kurzen Zeit sicher sportlich, aber wenn man die
> > Blockierer, die jeder aus dem Arbeitsumfeld kennt, erstmal
> > rausgeworfen hat, sollte das machbar sein.  
> 
> Klar. Wer kennt sie nicht, die Mitarbeiter, die immer nur dagegen
> sind? Einfach anpacken und gucken, wie weit man kommt.

Ich habe solche Leute schon erlebt. Die sind halt aus Prinzip dagegen
oder haben keine Lust auf Änderungen.

> > Überlegen, was die Software tun soll und das in einer dafür
> > geeigneten Sprache umsetzen, ohne den Altkram einzubeziehen.  
> 
> Insbesondere ersteres sollte eigentlich schnell erledigt sein.

Je nach Klientel ist auch das sehr schwierig.

> Schließlich ist der einzige Zweck der Software, Gesetze zu
> exekutieren - also braucht man selbige bloß zu lesen und in der
> Programmiersprache seiner Wahl in ausführbare Form zu bringen.

Wenn man diese Gesetze über Jahre aufbläht (so wie z.B. im dt.
Steuersystem), hat man am Ende ne sehr komplexe Logik. Ist dann halt so
und könnte man sich überlegen, bevor man die aufbläht.

> Nur zur Sicherheit: Du hast grob eine Ahnung, von welchem Umfang
> hier die Rede ist?

Wird ein Großprojekt. Wenn man aber gar nichts tut, bleibt die alte
Lösung - egal wie schlecht und wie lange die noch sinnvoll betreibbar
ist, ist auch eine Frage.

-- 
Gruß
Marco

Spam und Werbung bitte an
1743417033ichwillgesperrtwerden@nirvana.admins.ws

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

#636276

Marco Moock <mm+solani@dorfdsl.de> wrote:

> Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:
[US-Sozialsystem]
> > Nur zur Sicherheit: Du hast grob eine Ahnung, von welchem Umfang
> > hier die Rede ist?  
> 
> Wird ein Großprojekt. Wenn man aber gar nichts tut, bleibt die alte
> Lösung - egal wie schlecht und wie lange die noch sinnvoll betreibbar
> ist, ist auch eine Frage.

Die Lösung ist aber sicher nicht, mal schnell ein paar 'l3313 H4xx0r5
hinzuschicken.

Und frag' Dich vielleicht mal, wie es dazu gekommen ist - richtig, kein
Geld. Und das über lange, lange Zeit.

-- 
It rubs the AI on its devices or else it gets the hose again.

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

#636277

Am 31.03.25 um 17:56 schrieb Marco Moock:
> Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:

>> Klar. Wer kennt sie nicht, die Mitarbeiter, die immer nur dagegen
>> sind? Einfach anpacken und gucken, wie weit man kommt.

> Ich habe solche Leute schon erlebt. Die sind halt aus Prinzip dagegen
> oder haben keine Lust auf Änderungen.

Und das möglicherweise aus sehr guten Gründen. COBOL ist eine
kaufmännische Programmiersprache, also genau für diesen Zweck.
Nun muss mir mal jemand erklären, warum das in eine andere
Programmiersprache soll. Der Grund kann ja nicht ernsthaft
"weil es modern ist" sein.

Junger Freund, Du würdest staunen, wenn Du erfahren würdest,
wie viel in Banken, bei Versicherung und beim Staat in COBOL
läuft.

Übrigens kann man neue COBOL-Programmierer ausbilden. Und
das wird auch gemacht - nur macht da niemand so ein Gewese
drum.

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

#636285

On 31/03/2025 22:20, Martin Ebert wrote:
> Am 31.03.25 um 17:56 schrieb Marco Moock:
>> Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:
> 
>>> Klar. Wer kennt sie nicht, die Mitarbeiter, die immer nur dagegen
>>> sind? Einfach anpacken und gucken, wie weit man kommt.
> 
>> Ich habe solche Leute schon erlebt. Die sind halt aus Prinzip dagegen
>> oder haben keine Lust auf Änderungen.
> 
> Und das möglicherweise aus sehr guten Gründen. COBOL ist eine
> kaufmännische Programmiersprache, also genau für diesen Zweck.
> Nun muss mir mal jemand erklären, warum das in eine andere
> Programmiersprache soll. Der Grund kann ja nicht ernsthaft
> "weil es modern ist" sein.
> 
> Junger Freund, Du würdest staunen, wenn Du erfahren würdest,
> wie viel in Banken, bei Versicherung und beim Staat in COBOL
> läuft.
> 
> Übrigens kann man neue COBOL-Programmierer ausbilden. Und
> das wird auch gemacht - nur macht da niemand so ein Gewese
> drum.
> 

Ich bin sicher das auch in COBOL Weiterentwicklung gibt (Wie in FORTRAN) 
- aber ich sehe auch, das bei COBOL ein wenig Mief gesehen wird. Um 
ehrlich zu sein, ist bei mir nicht anders - wohl auch weil man wenig 
um/von COBOL hört (ausser es knallt mal wieder).

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

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

#636576

Am 01.04.25 um 10:19 schrieb Goetz Schultz:
> On 31/03/2025 22:20, Martin Ebert wrote:

>> Junger Freund, Du würdest staunen, wenn Du erfahren würdest, wie
>> viel in Banken, bei Versicherung und beim Staat in COBOL läuft.

> Ich bin sicher das auch in COBOL Weiterentwicklung gibt (Wie in
> FORTRAN) - aber ich sehe auch, das bei COBOL ein wenig Mief gesehen
> wird. Um ehrlich zu sein, ist bei mir nicht anders -

Es gibt riesige produktive Projekte, ursprünglich hunderte von Mannjahren.

> wohl auch weil man wenig um/von COBOL hört (ausser es knallt mal
> wieder).
  
Das sind Projekte im Kernbereich. Da gibt es NDAs ohne Ende.

Es gibt ein anderes, sehr reales Problem in diesem Bereich: Es gibt da
nicht ganz so große Projekte, da war die Dokumentation weniger prall,
teils nicht gegeben. Die laufen noch, aber es weiß niemand so ganz genau,
was da im Maschinenraum passiert. Es gibt Leute, die verdienen sehr viel
Geld um genau das herauszufinden.

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

#636295

Am 31.03.2025 um 23:20 schrieb Martin Ebert:

> Und das möglicherweise aus sehr guten Gründen. COBOL ist eine
> kaufmännische Programmiersprache, also genau für diesen Zweck.
> Nun muss mir mal jemand erklären, warum das in eine andere
> Programmiersprache soll. Der Grund kann ja nicht ernsthaft
> "weil es modern ist" sein.
> 
> Junger Freund, Du würdest staunen, wenn Du erfahren würdest,
> wie viel in Banken, bei Versicherung und beim Staat in COBOL
> läuft.
> 
> Übrigens kann man neue COBOL-Programmierer ausbilden. Und
> das wird auch gemacht - nur macht da niemand so ein Gewese
> drum.

Vielleicht will man das auch nur weil neuere Sprachen eben effektiver
sind. Und Cobol-Programmierer sterben echt aus. Ich mein wer hat denn
auf sowas noch Bock, wo es genug Jobs für Java-Enterprise-Entwickler
gibt, oder C# oder für andere Nicht-Business-Anwendungen C++ oder
Rust.

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

#636577

Am 01.04.25 um 14:47 schrieb Bonita Montero:
> Am 31.03.2025 um 23:20 schrieb Martin Ebert:

>> Junger Freund, Du würdest staunen, wenn Du erfahren würdest,
>> wie viel in Banken, bei Versicherung und beim Staat in COBOL
>> läuft.
>>
>> Übrigens kann man neue COBOL-Programmierer ausbilden. Und
>> das wird auch gemacht - nur macht da niemand so ein Gewese
>> drum.

> Vielleicht will man das auch nur weil neuere Sprachen eben effektiver
> sind.

Dann wollen wir mal rechnen: Das Projekt hat 350 verbrauchte Mannjahre.
Neu schreiben auf Plattform XZ sind effektivere 120 Mannjahre. Du kannst
ja rechnen ... die Chefs dort können das auch: Dass vor zig Jahren ge-
codete und immer zeitnah angepasste Projekt läuft. Ein Neuprojekt kostet
120 x wollen wir nur brutto oder Gesamtkosten rechnen? Wir sind im zwei-
stelligen Millionenbereich. Gegen "das läuft mit hoch bezahlter Wartungs-
crew".

> Und Cobol-Programmierer sterben echt aus.

Nein, es gibt da schon Nachwuchs. Nicht sehr viel, es braucht ja auch
nicht sooo viele. Vor allem aber ist das Kernbereich von "unternehmens-
kritisch" und nicht selten auch KRITIS, Du wirst wegen einiger Unter-
schriften niemanden finden, der offen im usenet berichtet...

> Ich mein wer hat denn auf sowas noch Bock,

Mal abgesehen davon, dass das Geld stimmt: Das ist der ewige Kampf
zwischen Entwicklung und Wartung. Klar ist Wartung weniger sexy...

> wo es genug Jobs für Java-Enterprise-Entwickler gibt, 

Jeder dieser jungen Cobol-Entwickler wird Dich für diesen Satzteil
auslachen, für deren Denkschule ist das (Java-Gedöhns) Rummelplatz gegen
die hohe Schule der Finanzgenies.

P.S: Gleich wird der 'Spezialexperte für Alles' kommen und euch erklären,
dass das alles nicht stimmt und ich sowieso keine Ahnung habe. So wird
das sein. (Er ist in meinem Filter, Reaktion von mir ist nicht zu erwarten.)

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

#636604

Martin Ebert <mx300@gmx.net> wrote:

> Am 01.04.25 um 14:47 schrieb Bonita Montero:
> > Am 31.03.2025 um 23:20 schrieb Martin Ebert:  
> 
> >> Junger Freund, Du würdest staunen, wenn Du erfahren würdest,
> >> wie viel in Banken, bei Versicherung und beim Staat in COBOL
> >> läuft.
> >>
> >> Übrigens kann man neue COBOL-Programmierer ausbilden. Und
> >> das wird auch gemacht - nur macht da niemand so ein Gewese
> >> drum.  
> 
> > Vielleicht will man das auch nur weil neuere Sprachen eben
> > effektiver sind.  
> 
> Dann wollen wir mal rechnen: Das Projekt hat 350 verbrauchte
> Mannjahre. Neu schreiben auf Plattform XZ sind effektivere 120
> Mannjahre. Du kannst ja rechnen ... die Chefs dort können das auch:
> Dass vor zig Jahren ge- codete und immer zeitnah angepasste Projekt
> läuft. Ein Neuprojekt kostet 120 x wollen wir nur brutto oder
> Gesamtkosten rechnen? Wir sind im zwei- stelligen Millionenbereich.
> Gegen "das läuft mit hoch bezahlter Wartungs- crew".

Bzw. man plant bei ausreichendem Druck einen Ersatz, dies aber in der
Form, dass den Anforderungen genüge getan ist und die Neuentwicklung
halt drei Jahre später ohne viel Gedöns beerdigt wird.

> > Und Cobol-Programmierer sterben echt aus.  
> 
> Nein, es gibt da schon Nachwuchs. Nicht sehr viel, es braucht ja auch
> nicht sooo viele. Vor allem aber ist das Kernbereich von
> "unternehmens- kritisch" und nicht selten auch KRITIS, Du wirst wegen
> einiger Unter- schriften niemanden finden, der offen im usenet
> berichtet...

Auch im KRITIS-Bereich gibt es Unternehmen, deren IT in die 60er zurück
reicht. Und COLBOL ist im Vergleich z.B. zu PL/1 oder hostseitigem C
*eigentlich* gar nicht soooo schlimm, ibs. wenn der, vielleicht gar
noch teilweise in FORTRAN geschriebene, Rechenkern seine letzten
schweren Bugs hatte, als man Jahreszahlen noch mit 198 begann.

> > Ich mein wer hat denn auf sowas noch Bock,  
> 
> Mal abgesehen davon, dass das Geld stimmt: Das ist der ewige Kampf
> zwischen Entwicklung und Wartung. Klar ist Wartung weniger sexy...

COBOLde werden iirc recht gut bezahlt und wenn man bei der Einstellung
darauf achtet, nicht nur Einhörner zu berücksichtigen ...

> > wo es genug Jobs für Java-Enterprise-Entwickler gibt,   
> 
> Jeder dieser jungen Cobol-Entwickler wird Dich für diesen Satzteil
> auslachen, für deren Denkschule ist das (Java-Gedöhns) Rummelplatz
> gegen die hohe Schule der Finanzgenies.

Tja. Das passiert insbesondere, wenn bei der Ausbildung geschlampt
wurde. Dick Size Wars gerne beim Bier nach der Arbyt.
Wer sowas aber in seiner bezahlten Zeit macht hat in meinen Projekten
ggf. wenig Spaß. Das gilt natürlich für alle Beteiligten. Ich habe
keine Zeit für Frontend kappelt mit Backend, beide schimpfen auf Ops
usw. usw.. Ein bisschen Spass darf ja sein, aber bitte nicht mehr als
0,23% der Zeit.

> P.S: Gleich wird der 'Spezialexperte für Alles' kommen und euch

Du solltest davon absehen, bei Gebauer abzuschreiben oder deine
gelegentlichen Allüren auf Deine Gegenüber zu projizieren. Das führt
nur dazu, dass man Dir solches in angemessen Worten um die Ohren haut
und dann bist Du wieder beleidigt, du Mimose.

> erklären, dass das alles nicht stimmt und ich sowieso keine Ahnung
> habe.

Oh, wenn mal wieder Deine üblen Hetzereien wg. Stadt vs. Land und der
üblen Killerwindräder kommen, dann wirst Du halt mit Gegenworten
rechnen müssen.

> So wird das sein.

Warum, wenn Du, was nicht sooo häufig vorkommt, mal was halbwegs
sinnvolles schreibst?

> (Er ist in meinem Filter, Reaktion von mir ist nicht zu erwarten.)

Danke, danke. Ich sehe das als Auszeichnung.

-- 
It rubs the AI on its devices or else it gets the hose again.

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

#636610

Am 05.04.2025 um 02:51 schrieb Martin Ebert:

>> Vielleicht will man das auch nur weil neuere Sprachen eben effektiver
>> sind.

> Dann wollen wir mal rechnen: Das Projekt hat 350 verbrauchte Mannjahre.
> Neu schreiben auf Plattform XZ sind effektivere 120 Mannjahre. ...

Ich hab nicht für den Umbau gesprochen nur, dass modernere Sprachen
eben effektiver sind.

> Nein, es gibt da schon Nachwuchs. ...

Ich glaubs eher nicht. Nen Bekannter ist Cobol-Programmierer und die
suchen Leute und da ist das wie mit C++-Entwicklern: es meldet sich
auf die Anzeigen keiner der sich auskennt. Ich kenne das selbe aus
der C++-Welt: die Stellenanzeigen stehen über Jahre.

> Mal abgesehen davon, dass das Geld stimmt: Das ist der ewige Kampf
> zwischen Entwicklung und Wartung. Klar ist Wartung weniger sexy...

Ich würd nicht wie vor 30 Jahren programmieren wollen. Bin C++-Ent-
wicklerin und würde auch keinen Job nehmen der auf C++98 festgelegt
ist. Cobol ist ja wohl ein ähnlicher Anachronismus.

>> wo es genug Jobs für Java-Enterprise-Entwickler gibt, ...

> Jeder dieser jungen Cobol-Entwickler wird Dich für diesen Satzteil
> auslachen, für deren Denkschule ist das (Java-Gedöhns) Rummelplatz
> gegen die hohe Schule der Finanzgenies.

Ach Gott, welchem Kindergarten bist Du denn entsprungen ?

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

#636767

Am 05.04.25 um 13:17 schrieb Bonita Montero:

> Ich würd nicht wie vor 30 Jahren programmieren wollen.

Vor ca 30 Jahren ( windows 95 Zeiten )
habe ich die Lust an C++ verloren und bin zu (ANSI) C
zurückgekehrt.

> Bin C++-Entwicklerin und würde auch keinen Job nehmen
> der auf C++98 festgelegt ist.
> Cobol ist ja wohl ein ähnlicher Anachronismus.

Beruflich habe ich teilweise in C entwickelt.
Jetzt entwickele ich privat manchmal etwas in Python3
gelegentlich auch etwas erweitertes ANSI C.

Mein beruflich selbst entwickelte Zahl in COBOL
dürften ca 3 kleine Programme gewesen sein.

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

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

#636775

Am 07.04.2025 um 14:16 schrieb Hermann Riemann:

> Am 05.04.25 um 13:17 schrieb Bonita Montero:

>> Ich würd nicht wie vor 30 Jahren programmieren wollen.

> Vor ca 30 Jahren ( windows 95 Zeiten )
> habe ich die Lust an C++ verloren und bin zu (ANSI) C
> zurückgekehrt.

Schön doof. C++ ist einfach Lichtjahre produktiver und wartbarer.

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

#636779

Am 07.04.25 um 15:47 schrieb Bonita Montero:
> Am 07.04.2025 um 14:16 schrieb Hermann Riemann:
> 
>> Am 05.04.25 um 13:17 schrieb Bonita Montero:
> 
>>> Ich würd nicht wie vor 30 Jahren programmieren wollen.
> 
>> Vor ca 30 Jahren ( windows 95 Zeiten )
>> habe ich die Lust an C++ verloren und bin zu (ANSI) C
>> zurückgekehrt.
> 
> Schön doof. C++ ist einfach Lichtjahre produktiver und wartbarer.

Ich vermute, das Pixelbearbeitungen in Bildbereichen
in C mit pointer besser geht als irgendwelche Klassenkonstrukte in C++.

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

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

#636786

Am 07.04.25 um 17:01 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Ich vermute, das Pixelbearbeitungen in Bildbereichen
>> in C mit pointer besser geht als irgendwelche Klassenkonstrukte in C++.
> 
>    Gerade Graphik wird ja oft als Beispiel für objektorientierte
>    Programmierung verwendet, wenn man zeigt, wie graphische Objekte
>    (wie Rechtecke oder Kreise) sich selber zeichnen können, weil sie
>    jeweils wissen, wie sie auf das Kommando "zeichnen" reagieren:
 >

Ich bearbeite Pixel und keine Buchstaben.
Ausschnitte:

union  pixel_ { int i; struct { uchar b,g,r,m; }; };
struct pixels_{ union pixel_ *p,*p2; int w,h; size_t alloc_size;};
..

Die Arithmetik sieht ähnlich aus
nur ohne  verwirrende static cast<irgendwas>

static void sdl_storage_for_pixels_(struct pixels_ *pic, int64_t l){
    if ( pic->p!=NULL) free(pic->p);
    pic->p=malloc(l); pic->alloc_size = l;
    if (pic->p==NULL)
       error("sdl_storage_for_pixels: malloc return NULL",NULL,l);}

void sdl_full_box    ( struct pixels_      *tar, int color   ){
    int l,*p; l= tar->w * tar->h; storage_for_pixels(tar,4*l);
    p=(int*)tar->p; while( l-- >0) *p++=color;}
void sdl_empty_box   ( struct pixels_      *tar, int w, int h){
    int l; l=4*w*h; tar->w=w; tar->h=h; storage_for_pixels(tar,l);}
..


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

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

#636788

Am 07.04.25 um 17:54 schrieb Stefan Ram:
> Hermann Riemann <nospam.ng@hermann-riemann.de> schrieb oder zitierte:
>> Die Arithmetik sieht ähnlich aus
>> nur ohne  verwirrende static cast<irgendwas>
> 
>    In dieser Schleife wurde "int" als Datentyp verwendet, obwohl
>    eigentlich meist ein "size_t"-Wert benötigt wird.

Bei Bilder ab Größenordnung  64k*32k?
Dann würde ich in der Schleife uint64_t nehmen.

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

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

#636792

Am 07.04.2025 um 18:03 schrieb Hermann Riemann:

> Bei Bilder ab Größenordnung  64k*32k?
> Dann würde ich in der Schleife uint64_t nehmen.

Für nen Index eines Arrays im Speicher nimmt nan ein size_t und man
muss sich über die darunterliegende Plattform keine Gedanken machen.
Die C++-Container vector<>, array<> und basic_string<> indizieren
auch mit einem size_t.

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

#636791

Am 07.04.2025 um 17:48 schrieb Hermann Riemann:

> static void sdl_storage_for_pixels_(struct pixels_ *pic, int64_t l){
>     if ( pic->p!=NULL) free(pic->p);
>     pic->p=malloc(l); pic->alloc_size = l;
>     if (pic->p==NULL)
>        error("sdl_storage_for_pixels: malloc return NULL",NULL,l);}
> 
> void sdl_full_box    ( struct pixels_      *tar, int color   ){
>     int l,*p; l= tar->w * tar->h; storage_for_pixels(tar,4*l);
>     p=(int*)tar->p; while( l-- >0) *p++=color;}
> void sdl_empty_box   ( struct pixels_      *tar, int w, int h){
>     int l; l=4*w*h; tar->w=w; tar->h=h; storage_for_pixels(tar,l);}

Die Sprache ist doch komplett für'n Arsch.

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

#636790

Am 07.04.2025 um 16:12 schrieb Hermann Riemann:

> Ich vermute, das Pixelbearbeitungen in Bildbereichen
> in C mit pointer besser geht als irgendwelche Klassenkonstrukte in C++.

Da wo man in C einen Pointer hat hat man in C++ meist einen Iterator.
Der ist genauso effizient wie ein Pointer, aber man hat bei MSVC stan-
dardmäßig dann Bounds-Checking mit dem Iterator, bei der libstdc++ von
g++ und clang++ optional wenn man irgendwelche Makros definiert. Out-of
-bounds Fehler macht jeder mal, aber so findet man die dann relativ
leicht.
Aber das ist nur ein Sprachmerkmal, was einem das Leben leichter macht.
Allein die Container sind ein gigantischer Produktivitäts-Vorteil.

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

#636288

On Mon, 31 Mar 2025 17:56:04 Marco Moock wrote:
> Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:
>> On Sun, 30 Mar 2025 20:25:12 Marco Moock wrote:
>> > Am 30.03.2025 19:45 Uhr schrieb Hermann Riemann:  
>> >> Die US-Behörde für Bürokratieabbau will eine elementare
>> >> Programmiersprache in kürzester Zeit ersetzen.  
 
>> > Wird in der kurzen Zeit sicher sportlich, aber wenn man die
>> > Blockierer, die jeder aus dem Arbeitsumfeld kennt, erstmal
>> > rausgeworfen hat, sollte das machbar sein.  
 
>> Klar. Wer kennt sie nicht, die Mitarbeiter, die immer nur dagegen
>> sind? Einfach anpacken und gucken, wie weit man kommt.

> Ich habe solche Leute schon erlebt. Die sind halt aus Prinzip
> dagegen oder haben keine Lust auf Änderungen.

Ich sage ja: Wer kennt sie nicht?

Nur in jungen Jahren ist man der Meinung, dass man deshalb alles,
wogegen irgendjemand protestiert, einfach über den Haufen werfen und
besser machen kann. Glück hat, wer das dann mit einem Projekt
probiert, das überschaubar genug ist. Nun kenne ich zwar das
amerikanische Sozialversicherungssystem nicht, instinktiv würde ich
es aber eher nicht als Übungsgegenstand empfehlen.

>> Schließlich ist der einzige Zweck der Software, Gesetze zu
>> exekutieren - also braucht man selbige bloß zu lesen und in der
>> Programmiersprache seiner Wahl in ausführbare Form zu bringen.

> Wenn man diese Gesetze über Jahre aufbläht (so wie z.B. im dt.
> Steuersystem), hat man am Ende ne sehr komplexe Logik. Ist dann
> halt so und könnte man sich überlegen, bevor man die aufbläht.

Du hast auch von politischer Entscheidungsfindung nicht sehr viel
Ahnung, kann das sein? :-)

Ausser ein paar Juristen, die gut daran verdienen, will niemand
komplizierte Gesetze. Auch Politiker nicht, auch Lobbyisten nicht.
Nur, dummerweise, hätte jeder gerne ein ganz anderes, einfaches
Gesetz.

>> Nur zur Sicherheit: Du hast grob eine Ahnung, von welchem Umfang
>> hier die Rede ist?

> Wird ein Großprojekt. Wenn man aber gar nichts tut, bleibt die
> alte Lösung - egal wie schlecht und wie lange die noch sinnvoll
> betreibbar ist, ist auch eine Frage.

Ob sie überhaupt *so* schlecht ist, lässt sich von hier aus schwer
beurteilen. Aber selbst wenn, dann muss so etwas - auch wenn es
Schmerzen verursacht - gleich in einer Größenordnung von Jahren
geplant werden. Lässt sich dann allerdings nicht so gut vermarkten,
schon klar.

Servus,
   Stefan

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

Stefan - Entspannung ohne wenn und aber!
(Sloganizer)

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

#636289

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) posted:

> On Mon, 31 Mar 2025 17:56:04 Marco Moock wrote:
> > Am 31.03.2025 12:30 Uhr schrieb Stefan Froehlich:
> >> On Sun, 30 Mar 2025 20:25:12 Marco Moock wrote:
> >> > Am 30.03.2025 19:45 Uhr schrieb Hermann Riemann:  
> >> >> Die US-Behörde für Bürokratieabbau will eine elementare
> >> >> Programmiersprache in kürzester Zeit ersetzen.  
>  
> >> > Wird in der kurzen Zeit sicher sportlich, aber wenn man die
> >> > Blockierer, die jeder aus dem Arbeitsumfeld kennt, erstmal
> >> > rausgeworfen hat, sollte das machbar sein.  
>  
> >> Klar. Wer kennt sie nicht, die Mitarbeiter, die immer nur dagegen
> >> sind? Einfach anpacken und gucken, wie weit man kommt.
> 
> > Ich habe solche Leute schon erlebt. Die sind halt aus Prinzip
> > dagegen oder haben keine Lust auf Änderungen.
> 
> Ich sage ja: Wer kennt sie nicht?
> 
> Nur in jungen Jahren ist man der Meinung, dass man deshalb alles,
> wogegen irgendjemand protestiert, einfach über den Haufen werfen und
> besser machen kann. Glück hat, wer das dann mit einem Projekt
> probiert, das überschaubar genug ist. Nun kenne ich zwar das
> amerikanische Sozialversicherungssystem nicht, instinktiv würde ich
> es aber eher nicht als Übungsgegenstand empfehlen.
> 
> >> Schließlich ist der einzige Zweck der Software, Gesetze zu
> >> exekutieren - also braucht man selbige bloß zu lesen und in der
> >> Programmiersprache seiner Wahl in ausführbare Form zu bringen.
> 
> > Wenn man diese Gesetze über Jahre aufbläht (so wie z.B. im dt.
> > Steuersystem), hat man am Ende ne sehr komplexe Logik. Ist dann
> > halt so und könnte man sich überlegen, bevor man die aufbläht.
> 
> Du hast auch von politischer Entscheidungsfindung nicht sehr viel
> Ahnung, kann das sein? :-)
> 
> Ausser ein paar Juristen, die gut daran verdienen, will niemand
> komplizierte Gesetze. Auch Politiker nicht, auch Lobbyisten nicht.
> Nur, dummerweise, hätte jeder gerne ein ganz anderes, einfaches
> Gesetz.

Oft reicht der Wunsch nach einem Gesetz mit
besonders viel Einzelfallgerechtigkeit.

Aber Verweisungen auf Rechtsgrund oder -folgen,
insofern natürlich nicht ausdrücklich markiert,
machen die Sache gern komplexer.

Und nein, Kompromisse aus dem Dingensausschuß
von Stunde 3, an denen dann kein Jota mehr verändert
werden soll, sind oft auch nicht das Gelbe vom Ei.

Gruß, ULF

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

#636261

On 30/03/2025 18:45, Hermann Riemann wrote:
> Hallo
> 
> In
> 
> <https://www.heise.de/news/DOGE-will-offenbar-COBOL-bei-US-Sozialkasse- 
> ersetzen-innerhalb-von-Monaten-10333616.html>
> 
> steht:
> 
> Die US-Behörde für Bürokratieabbau will eine elementare 
> Programmiersprache in
> kürzester Zeit ersetzen.
> 
> Was denkt Ihr darüber?
> 

Generell: Kein Problem, möglicherweise sogar eine gute Idee in Richtung 
Wartbarkeit.

Mein Problem ist mit "in kürzester Zeit". Da wird dann wieder was 
hingerotzt, was keinen Bestand hat und nicht durchdacht ist. SW 
Entwicklung braucht Zeit und Planung, besonders bei komplexeren 
Aufgaben. Daher sehe eher negativ auf das Projekt.

> 
> Ein Einfall von mir:
> 
> COBOL - C Konverter dauert vielleicht zu lange.
> Aus Maschinencode eine Assembler Eingabe basteln?

Kommt immer drauf an, ein Programm 1:1 zu ersetzen geht nur zu einem 
gewissen Grad - irgendwann wird man sich verheddern (Ich habe mal 
versucht ein Fortran Programm nach C zu portieren - war ein grandioser 
Fehlschlag, nicht zuletzt weil das Fortan Programm für Großrechner 
geschrieben war (Stichwort: Ressourcen)).

-- 

Cheers,
    G.

Quis custodiet ipsos custodes?
---------------------------->8------------------------------
   /"\
   \ /  ASCII Ribbon Campaign
    X   against HTML e-mail
   / \
---------------------------->8------------------------------

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | ger.ct

csiph-web