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

Groups > ger.ct > #615317 > unrolled thread

Moderne Stellenanzeigen...

Back to article view | Back to ger.ct

Contents

  Moderne Stellenanzeigen... "F. W." <me@home.invalid> - 2024-02-09 10:22 +0100
    Re: Moderne Stellenanzeigen... Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-09 12:36 +0100
      Re: Moderne Stellenanzeigen... Walter Brill <WalterBrill@t-online.de> - 2024-02-09 15:12 +0100
        Re: Moderne Stellenanzeigen... Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-09 17:55 +0100
    Re: Moderne Stellenanzeigen... Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-09 13:22 +0100
      Re: Moderne Stellenanzeigen... Matthias Eißing <meissing@gmx.de> - 2024-02-09 15:29 +0100
        Re: Moderne Stellenanzeigen... Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-09 15:50 +0100
          Re: Moderne Stellenanzeigen... Matthias Eißing <meissing@gmx.de> - 2024-02-09 16:12 +0100
            Re: Moderne Stellenanzeigen... Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-09 16:29 +0100
          Re: Moderne Stellenanzeigen... Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-09 18:01 +0100
            Re: Moderne Stellenanzeigen... Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-09 19:13 +0100
              Re: Moderne Stellenanzeigen... Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-10 10:38 +0100
                Re: Moderne Stellenanzeigen... Bonita Montero <Bonita.Montero@gmail.com> - 2024-02-10 11:11 +0100
        Re: Moderne Stellenanzeigen... Hermann Riemann <nospam.ng@hermann-riemann.de> - 2024-02-09 17:56 +0100
      Re: Moderne Stellenanzeigen... Nomen Nescio <nobody@dizum.com> - 2024-02-09 16:29 +0100
    Re: Moderne Stellenanzeigen... Walter Brill <WalterBrill@t-online.de> - 2024-02-09 15:06 +0100

#615317 — Moderne Stellenanzeigen...

Ich lasse mir interessehalber von XING seit einiger Zeit Stellenangebote
für Entwickler schicken. Zwar stehe ich vier Jahre vor der Rente und
suche keine Stelle, mich interessiert aber immer, mit welchen Werkzeugen
heute so gearbeitet wird. Und das Studium der Stellenanzeigen ist da die
größte Quelle.

Das Ergebnis ist bewundernswert. Da scheinen Leute gesucht zu werden,
die MS-Office neu schreiben, das Internet neu sortieren, dabei auf einem
Bein tanzen und "La Paloma" mit den Arschbacken pfeifen. Und alles vor
der Frühstückspause.

Nein, im Ernst: von C++ über Java, von Ruby bis Python und natürlich SQL
wird alles aufgeführt, was heute in den IT-Postillen steht.
Webentwickler müssen natürlich auch noch HTML, CSS, Javascript und SQL
können, was alles mit PHP dokumentiert wird.

Also als ich als Entwickler arbeitete (1990 - 1998), da mussten wir C
können. Klar, das Internet war noch kein Raum für Anwendungen.
Allerdings hatten wir Leute für die Datenbank (die SQL konnten), Leute
für die Website (die HTML konnten) und natürlich Leute für die GUI (die
Ressourcen-Files erstellen konnten und sich um die CHM kümmerten).

Ich programmiere zum Glück nur noch auf eigene Rechnung. Dazu nehme ich
Pascal für alles. Das klingt vielleicht merkwürdig, aber man könnte hier
sofort auch C nutzen. Allerdings kann man natürlich mit Lazarus auch
Android-Anwendungen bauen und mit FastCGI steht eine bewährte Technik
für das Web zur Verfügung.

Ich persönlich finde das Chaos aus HTML und CSS alleine schon
verwirrend. Kommt noch Javascript und PHP dazu, wird es noch komplexer.
Ein Projekt, das außerdem noch SQL und C# braucht, hielte ich für
vollkommen fehlgeplant.

Mein Vorteil: man muss nur wenige Dinge können, die aber beherrschen.
Was mir z. B. viel leichter fällt, als einen Fehler in sechs Skripten
aus vier verschiedenen Sprachen zu suchen.

Das muss heute anscheinend alles aus einer Hand kommen. Täuscht der
Eindruck? Ist da keine Ordnung mehr?

FW

[toc] | [next] | [standalone]

#615322

Am 09.02.24 um 10:22 schrieb F. W.:

> Nein, im Ernst: von C++ über Java, von Ruby bis Python und natürlich SQL
> wird alles aufgeführt, was heute in den IT-Postillen steht.
> Webentwickler müssen natürlich auch noch HTML, CSS, Javascript und SQL
> können, was alles mit PHP dokumentiert wird.

Ein echter Programmierer programmiert in jeder Sprache FORTRAN.
HTML 3.2 ist noch einfach und lässt sich per Hand nach html5 und CSS 
konvertieren.
( Siehe Quelltexte meiner homepage  )

> Also als ich als Entwickler arbeitete (1990 - 1998), da mussten wir C
> können.

Als ich als Entwickler 1978 anfing,
kannte ich auch die Sprache nicht, in der mir ein Produktteil vorgesetzt 
wurde. Die Sprache machte mir keine Schwierigkeiten,
aber die Menge, die programmiert worden ist.

> Klar, das Internet war noch kein Raum für Anwendungen.
> Allerdings hatten wir Leute für die Datenbank (die SQL konnten), Leute
> für die Website (die HTML konnten) und natürlich Leute für die GUI (die
> Ressourcen-Files erstellen konnten und sich um die CHM kümmerten).

Beruflich war bei mir internet eine unbedeutende Randerscheinung.

> Ich persönlich finde das Chaos aus HTML und CSS alleine schon
> verwirrend.

Das hängt davon ab, wie viel davon benutzt wird.
Ich verwende gerne html, allerdings nur einen kleinen Teil
von den vielen tags ( Schlüsselwörte ) und Attribute.

> Kommt noch Javascript und PHP dazu, wird es noch komplexer.

Meine JavaScript Kenntnisse haben seit 2000 kaum zugenommen.
PHP brauche ich nicht, unterschiedliche html Seiten
bastele ich mit Python.

> Ein Projekt, das außerdem noch SQL und C# braucht, hielte ich für
> vollkommen fehlgeplant.

Datenbanken habe ich privat nie verwendet.

> Mein Vorteil: man muss nur wenige Dinge können, die aber beherrschen.

Nur so weit, wie ich sie brauche.
Sonst komme ich mit lernen ( und vergessen ) nicht nach.

> Was mir z. B. viel leichter fällt, als einen Fehler in sechs Skripten
> aus vier verschiedenen Sprachen zu suchen.

Eine Frage der debug Technik.
Meist verwende ich print für vermutlich relevante Stellen.

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

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

#615347

Hallo,

Am 09.02.24 um 12:36 schrieb Hermann Riemann:
> Am 09.02.24 um 10:22 schrieb F. W.:
> 
>> Nein, im Ernst: von C++ über Java, von Ruby bis Python und natürlich SQL
>> wird alles aufgeführt, was heute in den IT-Postillen steht.
>> Webentwickler müssen natürlich auch noch HTML, CSS, Javascript und SQL
>> können, was alles mit PHP dokumentiert wird.
> 
> Ein echter Programmierer programmiert in jeder Sprache FORTRAN.
> HTML 3.2 ist noch einfach und lässt sich per Hand nach html5 und CSS 
> konvertieren.
> ( Siehe Quelltexte meiner homepage  )


"lässt sich per Hand nach html5 und CSS konvertieren.."
Autsch!

<body>
       <h1>Homepage von Hermann Riemann</h1>
       <table>
          <tr>
          <td class="h">
          <a href="tab/satire.html">Satire</a>
          <td class="l">Sammlung eigenen Unsinns.
          <tr>

;-)

Ciao
Walter

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

#615357

Am 09.02.24 um 15:12 schrieb Walter Brill:
> Hallo,
> 
> Am 09.02.24 um 12:36 schrieb Hermann Riemann:
>> Am 09.02.24 um 10:22 schrieb F. W.:
>>
>>> Nein, im Ernst: von C++ über Java, von Ruby bis Python und natürlich SQL
>>> wird alles aufgeführt, was heute in den IT-Postillen steht.
>>> Webentwickler müssen natürlich auch noch HTML, CSS, Javascript und SQL
>>> können, was alles mit PHP dokumentiert wird.
>>
>> Ein echter Programmierer programmiert in jeder Sprache FORTRAN.
>> HTML 3.2 ist noch einfach und lässt sich per Hand nach html5 und CSS 
>> konvertieren.
>> ( Siehe Quelltexte meiner homepage  )
> 
> 
> "lässt sich per Hand nach html5 und CSS konvertieren.."
> Autsch!
> 
> <body>
>        <h1>Homepage von Hermann Riemann</h1>
>        <table>
>           <tr>
>           <td class="h">
>           <a href="tab/satire.html">Satire</a>
>           <td class="l">Sammlung eigenen Unsinns.
>           <tr>
> 
> ;-)

Das ist, abgesehen von class und weglassenen von end tags, html3.2.
In html5 sind nicht mehr so viele end tags gefordert.
browser habe auch früher derartige fehlende end tags
problemlos akzeptiert.

Zugehörige all Zweck css Datei
<http://www.hermann-riemann.de/any.css>

Hermann
    der plant, demnächst die Leerzeichen am Zeilenanfang
    und vielleicht auch einige Zeilenwechsel zu entfernen.

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

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

#615330

Am 09.02.2024 um 10:22 schrieb F. W.:

> Ich programmiere zum Glück nur noch auf eigene Rechnung. Dazu nehme ich
> Pascal für alles. Das klingt vielleicht merkwürdig, aber man könnte hier
> sofort auch C nutzen. ...

Ich habe Pascal zuletzt zu Zeiten von Turbo Pascal genutzt, aber ich
bin mir sicher, dass ein aktuelles Object Pascal sich deutlich über C
hinaus entwickelt hat.
C hat meiner Meinung nur so einen hohen Stellenwert weil man schnell
in der Sprache drin ist und es Leuten entgegenkommt die so ein Lowlevel
-Mindset haben.

> Ich persönlich finde das Chaos aus HTML und CSS alleine schon
> verwirrend. Kommt noch Javascript und PHP dazu, wird es noch komplexer.
> Ein Projekt, das außerdem noch SQL und C# braucht, hielte ich für
> vollkommen fehlgeplant.

Ne, überhauptnicht, mit C# und Java ist man wirklich um ein Vielfaches
schneller fertig und das Endprodukt ist viel wartbarer. In C muss man
doch wirklich jeden Stein einzeln umdrehen.

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

#615350

Am 09.02.24 um 13:22 schrieb Bonita Montero:
> Ne, überhauptnicht, mit C# und Java ist man wirklich um ein Vielfaches
> schneller fertig und das Endprodukt ist viel wartbarer.

Hier sollte man nicht die Leistungsfähigkeit des Frameworks als Vorteil
auf die Sprache übertragen.

-- 
cu://Matthias.Eißing.de

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

#615352

Am 09.02.2024 um 15:29 schrieb Matthias Eißing:
> Am 09.02.24 um 13:22 schrieb Bonita Montero:
>> Ne, überhauptnicht, mit C# und Java ist man wirklich um ein Vielfaches
>> schneller fertig und das Endprodukt ist viel wartbarer.
> 
> Hier sollte man nicht die Leistungsfähigkeit des Frameworks als Vorteil
> auf die Sprache übertragen.

Für C# gilt ja beides, bzw. die Sprache an sich ist ja voller
nützlicher Features. Und eigentlich ist es egal ob die Runtime
die Arbeitserleichterung macht oder die Sprache selbst.
C finde ich für heutige Fälle einfach indiskutabel aufwändig
zu programmieren. Aber manche Entwickler wollen eben jedes
Bit persönlich begrüßen

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

#615353

Am 09.02.24 um 15:50 schrieb Bonita Montero:
> C finde ich für heutige Fälle einfach indiskutabel aufwändig
> zu programmieren. Aber manche Entwickler wollen eben jedes
> Bit persönlich begrüßen

"C" hat IMHO nur noch eine Berechtigung: Wenn man jedes Bit persönlich
ansprechen *muss*; zB Mikrocontroller (insb. bei sehr limitierten
Ressourcen, wie RAM)

-- 
cu://Matthias.Eißing.de

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

#615354

Am 09.02.2024 um 16:12 schrieb Matthias Eißing:

> "C" hat IMHO nur noch eine Berechtigung: Wenn man jedes Bit persönlich
> ansprechen *muss*; zB Mikrocontroller (insb. bei sehr limitierten
> Ressourcen, wie RAM)

Bei solchen Mini-Anwendungen ist gg. C auch nichts einzuwenden weil
die ja eh klein sind. Alles darüber hinaus ist wie Mäuse melken.

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

#615359

Am 09.02.24 um 15:50 schrieb Bonita Montero:

> Aber manche Entwickler wollen eben jedes Bit persönlich begrüßen.

Oder byte

union  pixel_{ int i; struct { uchar b,g,r,m; };};

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

#615367

Am 09.02.2024 um 18:01 schrieb Hermann Riemann:
> Am 09.02.24 um 15:50 schrieb Bonita Montero:
> 
>> Aber manche Entwickler wollen eben jedes Bit persönlich begrüßen.
> 
> Oder byte
> 
> union  pixel_{ int i; struct { uchar b,g,r,m; };};

Ne union ist nach C-Standard kein sicheres Aliasing.

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

#615378

Am 09.02.24 um 19:13 schrieb Bonita Montero:
> Am 09.02.2024 um 18:01 schrieb Hermann Riemann:
>> Am 09.02.24 um 15:50 schrieb Bonita Montero:
>>
>>> Aber manche Entwickler wollen eben jedes Bit persönlich begrüßen.
>>
>> Oder byte
>>
>> union  pixel_{ int i; struct { uchar b,g,r,m; };};
> 
> Ne union ist nach C-Standard kein sicheres Aliasing.

Lücke im C-Standard?

Extra memcpy  int nach struct ist mir zu umständlich und zu langsam.
Ebenso die Typ Konvertierung mit void*

Hermann
    der obiges aus seinen jahrelang problemlos
    funktionierende Grafikprogrammen kopiert hat.
    ( Und von Fortran EQUIVALENCE kennt. )

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

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

#615384

Am 10.02.2024 um 10:38 schrieb Hermann Riemann:
> Am 09.02.24 um 19:13 schrieb Bonita Montero:
>> Am 09.02.2024 um 18:01 schrieb Hermann Riemann:
>>> Am 09.02.24 um 15:50 schrieb Bonita Montero:
>>>
>>>> Aber manche Entwickler wollen eben jedes Bit persönlich begrüßen.
>>>
>>> Oder byte
>>>
>>> union  pixel_{ int i; struct { uchar b,g,r,m; };};
>>
>> Ne union ist nach C-Standard kein sicheres Aliasing.
> 
> Lücke im C-Standard?

Es wird de-facto von allen Compilern unterstützt was Du da denkst, aber
garantiert ist das nicht. In C kannst Du alles als char-Array alias-en
und ein char-Array als alles. D.h. Du kannst die Adresse von irgendwas
gen char * casten und das wiederum gen irgendwas * und kannst somit
beliebiges Aliasing machen.
In C++ ist offiziell memcpy() die einzig legale Art des Aliasings. Ich
habe selbst so eine Klasse alias_ptr, die beliebige Iteratoren kapselt
die auf irgendwas zeigen was so groß wie ein char ist (requires
(sizeof(iter_value_t<It>) == 1 per C++20-Concept) und damit mache ich
dann mein Aliasing. rohes memcpy() wäre mir auch zu unleserlich. Damit
bin ich rein technisch auf der sicheren Seite. Da sieht man mal wieder
wie man komplizierte Probleme in C++ für den Nuter einer solchen Kompo-
nente relativ komfortabel lösen kann.


> Extra memcpy  int nach struct ist mir zu umständlich und zu langsam.

Das memcpy() mit Größen die nativen Datentypen entsprechen ist quasi
intrinsisch und wird in ein einzelnes Move übersetzt. Mein besagter
alias_ptr<> verlässt sich darauf.
Und grundsätzlich wär es ja eine Katastrophe wenn memcpy() einerseits
offiziell die einzige Art des legalen Aliasings in C++ wäre, anderer-
seits immer eine Library-Funktion aufgerufen würde.

Guck dir mal den Code an den folgende Funktion generiert:

#include <cstring>

int fn( float f )
{
	static_assert(sizeof(float) == sizeof(int), "");
	int x;
	std::memcpy( &x, &f, sizeof f );
	return x;
}

?fn@@YAHM@Z PROC
	movss	DWORD PTR [rsp+8], xmm0
	mov	eax, DWORD PTR f$[rsp]
	ret	0
?fn@@YAHM@Z ENDP

Wie man sieht: da ist kein Library-Call.

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

#615358

Am 09.02.24 um 15:29 schrieb Matthias Eißing:
> Am 09.02.24 um 13:22 schrieb Bonita Montero:
>> Ne, überhauptnicht, mit C# und Java ist man wirklich um ein Vielfaches
>> schneller fertig und das Endprodukt ist viel wartbarer.
> 
> Hier sollte man nicht die Leistungsfähigkeit des Frameworks als Vorteil
> auf die Sprache übertragen.

Das machte make schwieriger und behinderte grep erheblich.


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

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

#615355

Bonita Montero schrieb:
>Am 09.02.2024 um 10:22 schrieb F. W.:
>
>> Ich programmiere zum Glück nur noch auf eigene Rechnung. Dazu nehme ich
>> Pascal für alles. Das klingt vielleicht merkwürdig, aber man könnte hier
>> sofort auch C nutzen. ...
>
>Ich habe Pascal zuletzt zu Zeiten von Turbo Pascal genutzt, aber ich
>bin mir sicher, dass ein aktuelles Object Pascal sich deutlich über C
>hinaus entwickelt hat.

Allein die Speicher-Leaks zu orten, wenn man beim Freigeben geschlampt
hat, oder Pointer ins Nirwana, an Assembler erinnernde Erfahrungen
damals auf dem Amiga, die man eigentlich überwinden wollte, was mich
dann von dieser Pseudo-Hochsprache auch über Jahrzehnte hinaus
abschreckte. Wie viel wohler fühl(t)e ich mich da insbesondere bei
grösseren Projekten mit Pascal (Pascal @ C64 - Modula2 @ AmigaOS -
TurboPascal @ DOS - Delphi ... FreePascal / Lazarus @ Windows).

>C hat meiner Meinung nur so einen hohen Stellenwert weil man schnell
>in der Sprache drin ist und es Leuten entgegenkommt die so ein Lowlevel
>-Mindset haben.

Oder die Hardware-Ressourcen eines Microcontroller-Zielsystems begrenzt
sind. Da bleibt einem oft nur wenig Spielraum und man muss den erhöhten
Aufwand akzeptieren, wie z.B. hier der nun gelungene zweite Anlauf mit C
unter RTOS auf Espressif's ESP32-Serie.

Und dass C für Anfänger eingängiger ist als bspw. Pascal wage ich zu
bezweifeln.

>
>> Ich persönlich finde das Chaos aus HTML und CSS alleine schon
>> verwirrend. Kommt noch Javascript und PHP dazu, wird es noch komplexer.
>> Ein Projekt, das außerdem noch SQL und C# braucht, hielte ich für
>> vollkommen fehlgeplant.
>
>Ne, überhauptnicht, mit C# und Java ist man wirklich um ein Vielfaches
>schneller fertig und das Endprodukt ist viel wartbarer. In C muss man
>doch wirklich jeden Stein einzeln umdrehen.

Ja, Java in der Eclipse-IDE für Android-Apps empfand ich als sehr
angenehm, 'behütetes Programmieren' sozusagen. Und JSF für Webappli-
kationen mit angebundener SQL-Datenbank war auch grossartig, nicht
zuletzt, da man alles aus einem Guss hatte und sich nicht mehr getrennt
um den HTML/CSS-Schnickschnack kümmern musste. Ist nur mittlerweile
verpöhnt, da 'stateful'.

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

#615345

Hallo,

Am 09.02.24 um 10:22 schrieb F. W.:
> Ich lasse mir interessehalber von XING seit einiger Zeit Stellenangebote
> für Entwickler schicken. Zwar stehe ich vier Jahre vor der Rente und
> suche keine Stelle, mich interessiert aber immer, mit welchen Werkzeugen
> heute so gearbeitet wird. Und das Studium der Stellenanzeigen ist da die
> größte Quelle.
..
..
> Ich persönlich finde das Chaos aus HTML und CSS alleine schon
> verwirrend. Kommt noch Javascript und PHP dazu, wird es noch komplexer.
> Ein Projekt, das außerdem noch SQL und C# braucht, hielte ich für
> vollkommen fehlgeplant.
..

Wenn es um Webdesign und AI geht, gibt es schon den Ruf nach einer 
Gewerkschaft:

Ethan Marcotte
YOU DESERVE A TECH UNION
<https://abookapart.com/products/you-deserve-a-tech-union>

(Leseprobe):
<https://shopify-delivery-app-storage.s3.amazonaws.com/files/abookapart.myshopify.com/43240857993415/you-deserve-a-tech-union-CH5-PRV.pdf?X-Amz-Expires=86400&X-Amz-Date=20240207T164627Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJUUXOYY3VGOYS5UQ%2F20240207%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=6aa304e2f77353896febaa2b8441eb0fe19acffcc499136b8c2d4acca469aaac>

Ciao
Walter

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web