Wo findet man Programmierer?

OK, ich sehe wir reden teilweise von verschiedenen Größenordnungen. Posix-Aufrufe beim 8051 sind eher selten... :D

Bernd

Bernd Laengerich schrieb:

ie

"Olympia-A" bitte, quasi der "Chrom-Kadett-B-Coupe'". Den einen (mit Automatik) gibt es ja sogar noch, in Aurich in einer Scheune... Ja, der fliegende Wechsel war schon eine Konzentrationssache!

Jorgen

"Andreas Schwarz" schrieb im Newsbeitrag news:420a33d2$0$18566$ snipped-for-privacy@newsread4.arcor-online.net...

Davon kannst du ausgehen, doch ist hier die falsche NG um dir die Zusammenhaenge zu erklaeren. Du darfst auch davon aus gehen, das die Saetze, die ich schreibe, inhaltlich richtig sind, aber weil es die falsche NG ist, so kurz wie moeglich gebaut sind. Es ist Absicht, das im Satz eine Klassenaenderung genannt wird und was zum Speichern drin steht, und wenn dir die Problematik nicht bekannt ist, PM oder eine Gruppe wo das Thema hinpasst.

Hallo Oliver,

Oliver Bartels schrieb: [...]

=20

sch=F6n, dass ich doch nicht der einzige bin, der dieser Meinung ist :-) Wenn man sich heute im Netz umsieht, k=F6nnte man dem Irrtum erliegen, dass es heute nur noch LAMP etc. gibt, und man sich seine Anwendungen nur noch zusammenklicken muss. Dass allerdings bei nichttrivialen Programmen die Hauptarbeit im entwickeln von effizienten und eleganten Datenstrukturen und Algorithmen liegt, scheinen die wenigsten zu wissen. Aber ich denke, in dieser Gruppe hier brauchen wir das wohl nicht extra erw=E4hnen.

ciao Marcus

Keineswegs. FreePascal, VirtualPascal und Lazarus verstehen Delphi-Code, vermulich auch noch eine Reihe weiterer Compiler. Lazarus ist sogar ein Delphi-Klon der auf FreePascal aufsetzt. Sowohl FreePascal als auch VirtualPascal sind für verschiedene Betriebssysteme (Dos, Win, OS2,

Wenn man mal von all den Problemen mit den Bibliotheken absieht

Oder auf Sprachen die so kryptischen Code produzieren daß selbst der Programmierer der Software diese nach einm halben Jahr nicht mehr warten kann. Mit der Folge daß zB in M$-Word auch in der neuesten Version noch wohlbekannte Bugs enthalten sind, die schon seit der ersten Version bekannt und wohldokumentiert sind. Es findet sich halt niemand mehr durch den Code.

Hallo,

• Dr Engelbert Buxbaum [13.02.2005 13:47]:

Und du meinst wirklich das liegt an der Sprache und nicht am Programmierer? Schlechte Programmierer schaffen es, Code in jeder Sprache unverständlich zu schreiben

Gruß, Bernhard

Gewisse Tendenzen scheinen solches nahezulegen, ja:

Und fuer keine andere Sprache als C existieren so viele Guidelines, wie man damit "richtigen Code" schreiben sollte. Irgendwie scheint das also gar nicht so einfach zu sein.

Vinzent.

Vinzent 'Gadget' Hoefler schrieb:

Vielleicht liegt das auch einfach mal daran, dass sie zu den am weitesten verbreiteten liegt?

Du meinst, dass das der Grund ist, warum sich ausgerechnet C-Guidelines vorwiegend darauf beschraenken, zu beschreiben, wie man gewisse Dinge

Vinzent.

Vinzent 'Gadget' Hoefler schrieb:

C-Guidelines werden zum größten Teil von Managern abgefasst und sind mehr oder minder unsinnig. Eine ordentliche Codequalität können sie genauso wenig garantieren wie der bloße Umstieg auf eine alternative Programmiersprache. Wenn überhaupt, kann man sie bestenfalls benutzen, um eine Kollaboration von möglichst vielen sehr verschiedenen Programmierern zu vereinfachen.

Aber wir sind jetzt völlig OT hier. EOT.

C-Guidelines

Warum nicht?

C ist sicherlich nicht besonders daf=FCr predestiniert, als Programmiersprache f=FCr die breite Masse zu dienen. Zuviele Steuerzeichen und die enorme Wichtigkeit von Wortfolgen oder sogar Zeichenfolgen fordern einem "Anf=E4nger"=20 doch einiges ab. Eine etwa funktionsgleiche Pascal-Variante=20 w=E4re sicherlich geeigneter f=FCr die breite Masse. Meine zumindest ich.

Gruss

Jan Bruns

Weil sich die meisten Richtlinien fuer andere Sprachen darauf beschraenken, zu beschreiben, wie man $PROBLEM in der Sprache am effizientesten loest, nicht, wie man es besser nicht loest. ;-)

Offensichtlich tut es das aber.

Sie fordern auch einem "Profi" noch ausreichend ab.

Dass es so etwas bereits seit guten zwanzig Jahren gibt, scheint die "breite Masse" allerdings nicht sehr zu interessieren. :->

Fup2 gesetzt.

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

ind

Mir scheint, wir reden mal wieder aneinander vorbei. Ich rede von Dinge= n wie (das Original ist auf

zwar noch referenziert, fuehrt aber zu einem 404) und , nicht von irgendwelchen Stil-Richtlinien, die meinen, dass Software besser wird, wenn man unsigned-char-Variablen mit einem uc-Praefix versieht.

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

"Dr Engelbert Buxbaum" schrieb

Klar und es gab mal HP-Pascal und DEC-Pascal, das hat mich Wochen gekostet ein Programm von Pascal nach Pascal zu portieren ... ok ist nu auch schon ein etwas her *ggg* Dann kam Turbo-Pascal und nach jeder neuen Version durfte man den Code anpassen ...

Das war dann auch das letze was ich von Pascal gesehen habe ... halt, stimmt nicht ganz VHDL sieht auch so aus .

C und C++ Bibliotheken sind genormt und auf Quellcode Ebene ist es nicht schwer portierbaren Code zu schreiben.

Die einzigste "Sprache", mit der das ganz leicht geht ist TIKL/TK *ggg*

mfg Hans-Georg

"Vinzent 'Gadget' Hoefler" schrieb .

Diese Guidlines existieren nicht wegen der Sprache sondern weil ein Programmierer eben kein Einzelkämpfer ist und andere seinen Code verstehen müssen, wenn der Kunde auf der Matte steht und der Kerl gerade nicht greifbar ist. Weiterhin musst du schon einem Industriekunden nachweisen können nach welchen Regeln du programmierst und wie du validierst .... nennt sich Zertifizierung. Der Kunde hat da ein sehr starkes Interesse daran, sonst sitzt er auch da mit dem Code wenn dein Laden Pleite geht und du auch wenn dein Programmierer weg läuft.

Ich mach das nun schon fast 20 Jahre mit C, C++ und Java. Das reicht vollkommen aus. Warum soll eine Firma dann noch Ausbildung in andere Sprachen investieren, wenns nichts bringt. Visual Basic wurde auch schon mal vom Kunden vorgeschrieben. Pascal wollte noch keiner ...

Aber Privat kannste gerne mit Pascal und Delphi rumspielen, solange du Anwendungs-Programme für einen "kompatiblen PC" schreibst. Bei einem WDM-Treiber für Windows oder einem Kernel-Modul für Linux siehts da schon anders aus.

mfg Hans-Georg

MISRA-C bezieht sich hauptsaechlich auf Sprachkonstrukte, die es zu vermeiden oder explizit (nicht) zu verwenden gilt.

(BTW, AFAIK empfiehlt MISRA in ihrem Dokument die Nutzung anderer typsicherer Sprachen wie Ada oder Modula(-2).)

Das =BBDing=AB hier(tm) ist weder wirklich kompatibel, noch ein echter = PC, noch ein Anwendungsprogramm, noch wird es in Pascal oder gar Delphi entwickelt. (Es in C zu schreiben, waere im uebrigen Aufwand, den ich mir zeitlich gar nicht leisten kann.)

da

Das erwaehnte ich schon und das Hauptproblem dabei ist, dass die Schnittstelle zum OS eine makroverseuchte C-Schnittstelle ist und es deshalb nicht sonderlich einfach ist, entsprechend andere Sprachen daran anzubinden, weil das Linkbare, was sich hinter den Makros versteckt, sich jeden Moment aendern kann.

Das heisst allerdings noch nicht, dass C oder C++ die - wie geschrieben=

wurde - die einzigen Moeglichkeiten sind. Und wenn das noch laenger jemand behauptet, schreibe ich den Treiber wirklich noch um. Wenigstens=

kann ich dann nicht mehr ssize_t und int verwechseln.

Vinzent.

--=20 worst case: The wrong assumption there actually is one.

"Hans-Georg Lehnard":

Delphi-Code,

ein

Sehe ich auch so, soweit Du damit auf Delphi bezogene, von = OS-Entwicklern m=F6glicherweise in Zukunft erwirkte API-Inkompatiblit=E4ten ansprichst.

Ja, kann passieren, wenn man von einem Sprachstandard zum n=E4chsten=20 portiert. Ist bei C auch nicht viel anders. Z.B. lcc kann immer noch=20 nicht wenigstens mal die Makrobeispiele aus dem 1999c Standard richtig ersetzen. Und pl=F6tzlich taucht auch sowas wie C++ auf, wie=20 abw=E4rtskompatibel es auch sein mag.

Zu der Zeit hat man versucht, mit 16Bit Code eine 32-Bit Maschine voll auszukosten.

"as","any","each","from"? Sieht f=FCr mich eher nach VB aus. =20

Gerade erst in dclax: | [obere 32 Bit einer sigened 32x32-Bitmultiplikation] | ... | Wenn schon, dann | int32 c =3D (int64(a) * b) >> 32; | Das erzeugt zumindest mit dem gcc den gew=FCnschten Code.

Und die H=E4lfte davon ist sogar so ganau auf eine makefile/Compilerversion/Zielsystem-Kombination genormt, da=DF sie f=FCr keine andere Kombination verwendbar ist.

schreiben.

Das ist ja ganz was neues.

Also wenn Du mich fragst, ist C inetwa so leicht zu portieren, wie Assembler, wobei letzteres den Vorteil hat, da=DF die Portierung vollautomatisch funktioniert. Wenn Dir das Wort Assembler in diesem=20 Zusammenhang nicht gef=E4llt, denn kannst' ja Java Bytecode draus = machen.

Insofern sollte man doch eigentlich meinen, da=DF es gar nicht m=F6glich = ist, schwer portierbaren Code zu formulieren.

Dem ist leider nicht so. Der Trottel vom API-erstellungdienst von=20 $OS_Entwicklergruppe geht n=E4mlich zum definieren seiner Schnittstelle so vor:

mein_int32_typ =3D long; meine_datenstruktur =3D folgendes: eine_zahl : mein_int32_typ; ein byte : byte; noch_eine_zahl : mein_int32_typ; ende_meiner_datenstruktur;

dateiformat_zum_austausch_ueber_internet =3D meine_datenstruktur;

Diese darstellung ist schon weitestgehenst idealisiert, denn in der Praxis vergisst der Trottel vom API-erstellungdienst leider, sein_int32_typ als solchen zu kennzeichnen. Mit etwas Gl=FCck findet sich diese Information in der nicht maschinenlesbaren Doku wieder (sei es die von $OS_Entwicklergruppe erstellte, oder die =FCber den Standard hinausgehende $Compiler-Doku).=20

Ein Blick in den Standard zu der von $OS_Entwicklergruppe gew=E4hlten Programmiersprache f=FCr die API offenbart dann aber:

Der Trottel vom API-erstellungdienst war gar nicht schuld. Man kann in der gew=E4hlten Sprache n=E4mlich =FCberhaupt keine = portablen Datenstrukturen erstellen.

Gruss

Jan Bruns

(f'up nach de.comp.lang.misc gesetzt)

Oliver Bartels wrote:

Ich erleb eher das Gegenteil. "Da müssen sie halt umlernen" ist mittlerweile eins der häufigsten der arroganten Ausreden für disfunktionale Systeme. Beispiel 1: Wegen Aussterbens alter PCs musste bei mehreren Mess-Systemen die natürlich proprietären Platinen gewechselt werden. Plus Umbau des Messgeräts an sich. Plus, natürlich, Softwareupdate. So kostete das "Umdenken lernen" erst einmal etwa 5kE+10kE+7kE. Pro Arbeitsplatz, natürlich. Die neue Soft- ware ist umständlicher, was früher eine Einstellung war, benötigt heute mindestens 3, geschickt in Submenues versteckt. Und andere Sachen gehen nicht mehr. Andere kriegt man knapp mit üblen Workarounds doch noch hin, an denen hat der Hersteller auch lange rummurksen müssen (ätsch, Rechnung noch nicht bezahlt...). Viele Sachen kriegt man nur noch zum Laufen, da man sich mit Adventuregames einen krampfhaften Spieltrieb im Zusammenhang mit unlogischen Rätseln antrainiert hat. Die vorhergehende Version lief einwandfrei... Dafür kanns wohl irgendwelche Diagramme in 3D und mit Schatten- wurf und in Farbe. Dafür ist das Programm wirklich absturzsicher. Falls das angeschlossene Messgerät noch nicht eingeschaltet ist, stürzt es nicht ab. Allerdings schmiert XP ab... Neustart des Programms, ohne erneuten Systemabsturz, ist nur möglich, wenn gewisse Log-Dateien zuerst von Hand gefunden und gelöscht werden. Ja, toll, da muss man halt umlernen. Danke. Nicht die Informatiker müssen flexibel sein, sondern die Kunden. Als erstes muss man ihnen solche Märchen austreiben wie "Ein Computer ist ein frei programmierbarer Automat". Der Kunde muss programmiert werden, damit er die Anwendung richtig anwendet. Ein falscher Mausklick muss unmittelbar bestraft werden, was wäre da geeigneter als ein Systemabsturz. Ich finde es eher als unzumutbar, dass ich von den einen Informatikern als Mausepileptiker beschimpft werde. Die wollen mich von MS wegzwingen und deponieren Schimpf- und Hasstiraden auf diese Firma bei mir (warum eigentlich, es war doch *ihr" Rechenzentrum, welches das System bei mir zwangsinstalliert hat). Andere hingegen kriegte den Kasper als ich noch was auf der Command line machte und anfangs die Maus verweigerte. Soll ich jetzt täglich umlernen, nur damit diese offenbar in sich total zerstrittene Bande endlich Ruhe gibt? Welche Abteilung gibt in vielen Betrieben und Hochschulen den miesesten Service?

Beispiel 2, Autobus: Ja, wir haben jetzt schöne neue Busse von V*lv*. Früher konnte der Fahrer die Türen schliessen und weiterfahren. Das kann er heute natürlich auch. Meistens. Es ist nämlich sicherer geworden. Sind die Türen nicht zu, verhindert eine Anfahrsperre die Weiterfahrt. Manchmal eben auch dann, wenn die Türen zu sind. Oder plötzlich geht der Fahrkartenentwerter nicht mehr. Beide Pannen sind leicht zu beheben: Motor aus, Hauptschalter aus. 30 Sek warten. Dann neu Starten (Booten?). Und siehe da, alles funktioniert wieder. Da muss man halt umlernen...