Wo findet man Programmierer?

[Oliver Bartels]

On Sat, 5 Feb 2005 15:25:49 +0000 (UTC), Matthias Weingart
<mwnews@pentax.boerde.de> wrote:

Hrhr, den Dialog kann ich mir gut vorstellen.
Ich hab' langsam genug davon ;-/

Man muss aber auch mal
die andere Seite der Medaille sehen (der Busfahrer hat nicht so ganz
unrecht). Es soll eine CAD-Software bedienen, die eigentlich kaum die
gängigen Bedienregeln, die sich bei Windows so eingebürgert haben, hat.
Ach gel', wir reden hier nicht von Windows Bedienregeln, sondern

von den exakten Abläufen seiner alten EDA Software.

Der Lernwille bei einigen Leuten ist exakt null, manche glauben
auch, dass sie mit dem Diplom das lebenslange Recht zum
Geldverdienen ohne Weiterbildung erworben haben ...

Um beim Busfahrer zu bleiben, geht es eher darum, dass das Gaspedal mit
der linken Fuss zu betätigen ist und er zum Bremsen immer den Handgriff
hinter der rechten Schulter ziehen muss.
Jetzt lach bitte nicht, aber viele Rennfahrer bremsen mit dem

*linken* Fuß und bei den Rennmoppeds läuft aus gutem Grund
(Hochschalten in der Kurve) die Schaltung auch umgekehrt wie bei
Strassenmaschinen.

Und stell' Dir vor: Ich kann von einer Minute auf die andere von
meinem Mopped (Gas drehen mit rechter Hand, bremsen vorne
mit rechter Hand, Schalten mit linkem Fuß usw.) auf mein Auto
(Gas mit rechtem Fuß, Schalten mit Tipptronic) oder ein anderes
mit Schaltgetriebe (Kupplung mit linkem Fuß, schalten mit der
rechten Hand, also da, wo beim Mopped das Gas ist ... )
umsteigen, ohne dass dies zu Problemen führt.

Und ganz viele andere Menschen können das auch ...

Nur beim PC ist das Aktivieren der grauen Zellen im
Flexibilitätsareal irgendwie für manche Leute ein ganz ganz
großes Problem ...

Ciao Oliver

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10

 

[Olaf Kaluza]

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

Mhh, Delphi ist so lange verfügbar, wie Windows die WIN32-Api
unterstützt. Auch heute kann man noch Programme für Windows 3.1
schreiben (oder für Dos). Die Software verfällt ja nicht.

Kann du mir das nochmal erklaeren? Ich dachte bisher Delphi waere ein
Pascal fuer Windows mit grafischer Oberflaeche zum Fenster
zusammenklicken. Und solange es Windows gibt sollte es darauf laufen.
Unterliege ich da einem Irrtum?

Oder anders ausgedrueckt, ist damit zu rechnen das Programme in Delphi
unter Windows BSE nicht mehr laufen werden?

_noch nicht_, wenn man danach geht, was Billy plant wird das aber
sicher bald der Fall sein :-(.
Muss man denn immer updaten?

Genau, vielleicht kann man es ja irgendwann einfuehren das du einfach
alle zwei Jahre dein Geld nach Redmund ueberweisen darfst ohne eine
neue Version eines Betriebssystems zu installieren. Das waere schonmal
eine kleine Verbesserung. :-/


Olaf

 

[Olaf Kaluza]

Bernd Maier <bermai@directbox.com> wrote:

Hast du mal diese Internetstellenbörsen (gulp,...) probiert?

Das ueberlasse ich mal lieber meinem Chef.

Suchst du für eine langfristige Beschäftigung oder eher flexibel?

Bis zur Rente.

Olaf

 

[Jan Bruns]

"Bernhard Walle":

:

Für Office, Spiele, Mediaplayer, usw. hingegen macht das UI den
Hauptanteil der Programme aus.

Office ja, Spiele möglicherweise, Mediaplayer mit Sicherheit nicht.
Genau deshalb gibt es unter Linux z. B. die xine-lib, auf der
unterschiedliche UIs (Xine-UI, Kaffeine, gXine, Xfmedia, etc.) aufsetzen.

Ist unter win ähnlich. Da ist dann die lib Teil des OS.
Entsprechend verbleibt also auch beim Media-Player nur noch UI.

Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen
von Kommandozeilenaufrufparametern zumuten wollen. Natürlich kann man
denn noch die UI einfach bundlen, nur wo liegt da dann der Unterschied
zum fertig gelinkten binary? In der Freiheit, etwa sowas wie
"CALL Shell, TYPE Start" zu betreiben. Ausser Skript-Kiddies hat da
niemand was von, und selbst die können ersatzweise besser
"#include" tippen.

Ja, allerdings werden oftmals Programme geschrieben, wo GUI und
eigentlicher Code im Quellcode so vermengt sind, dass eine Portierung
auf ein anderes GUI-System einem Rewrite der kompletten Anwendung
gleichkommt, weil einfach keine Trennung vorhanden sind.

Also wirklich häufig wird auch das nicht sein.
Wie auch. Die GUI klicken sich doch viele in einem Editor zusammen,
der ja zumeist eher nicht von sich aus "richtig große Anwendungen" erzeugt.

In völlig anderen Bereichen ist es sogar einfach besser,
"engine + grafik-engine" eng zu verknüpfen. Z.B. hätten viele
Direct3D verwendende Spiele durchaus auch so programmiert werden können,
daß es einem wrapper überlassen wird, ob nun D3D oder OpenGL verwendet wird.
Damit hätte man ein vergleichsweise leicht portierbares, dafür aber
optisch suboptimales Produkt (da featurelimitiert und langsamer).
In diesem Sektor wird teilw. nicht nur Schnittstellenspezifisch, sondern
gar für konkrete Hardware/Treiber-Konfiguration optimiert geschrieben.
Geht halt nicht wirklich anders.

Aus dieser Richtung betrachtet sieht es schon irgendwie etwas kleinnüdelig
aus, wenn plötzlich z.B. die GUI-Konvertierung für ein Brennprogramm mehr
als etwas Aufwand bedeuten soll.

Und damit geht
es! GUI-Systeme ändern sich weit häufiger als Programmlogik und es gibt
mehrere GUI-Systeme (was weiß ich was meine Kunden in 5 Jahren von mir
haben wollen), so dass eine Trennung im Code bei einer vernünftigen
Anwendung ab einer bestimmten Größe einfach essententiell ist.

Sehe ich noch nicht so ganz. Nahmen wir als Beispiel mal ACAD.
Davon mag es in den letzten 10 Jahren vielleicht 7 releases gegeben haben.
Eine davon wegen Umstellung des UI von DOS auf WIN32.
Der Rest dürfte auf "Codeverbesserungen" wie "Körperschnitte", Gerätetreiber,
bessere Algos, CPU-spezifische Optimierungen, und weiß der Geier was nicht sonst
noch alles entfallen.
Sicherlich hätte es ACAD nie bis zur Marktreife geschafft, wenn die
Programmierer einzelne Programmodule nicht sorgfältig separiert hätten,
das aber doch nicht ernsthaft, weil womöglich irgendwann mal die
GUI-Anpassung mehr oder minder aufwendig gewesen sein mag.

Gruss

Jan Bruns

 

[Dieter Wiedmann]

Rainer Buchty schrieb:

Beim Computer hingegen ist man komischerweiser der Ansicht, daß das Ding so
wie ein Toaster zu bedienen sein muß. Immer gleich, ein Hebel, ein Stellrad.

An der Ähnlichkeit zum Toaster wird gearbeitet, zunächst mal im Bezug
auf die Heizleistung. Der Rest kommt später.


Gruß Dieter

 

[Rainer Buchty]

In article <cu32vs$9et$1@online.de>,
"Jan Bruns" <post@abnuto.de> writes:
|> Am Commodore128 standen noch die Worte "Personal Computer".=20

Das stand auch am 1981 PC.

Namen sind Schall und Rauch.

|> Der C128 war vollst=E4ndig C64-kompatibel. Selbst das Diskettenlaufwerk
|> dazu hatte einen Kompatiblit=E4tsmodus. Sowohl C128, als auch das
|> zugeh=F6rige Diskettenlaufwerk hatten zus=E4tzlich auch noch einen CP/M
|> Kompatiblit=E4tsmodus, der allerdings leider mit Fernseh-Anzeigeger=E4ten
|> inkompatibel war.

Das mußt Du mir nicht erzählen, C64 war "meine" Zeit. Allerdings war
der C128 diesbezüglich auch die einsame Ausnahme und vor allem auch nie
wirklich erfolgreich -- mit der CP/M-Kompatibilität kam er ein paar Jahre
zu spät. Da hätte er eher Erfolg gehabt, wenn er nen 8088 als Zusatzprozessor
besessen hätte und mit MSDOS gekonnt hätte.

Wäre er nicht C64-kompatibel gewesen, wäre er vermutlich so gut wie gar nicht
verkauft worden -- vgl. auch die "Profi"-Geräte der CBM600/700 Serie.

|> Letzlich hatte das Ger=E4t (+ die Floppy) weiters einen nativen =
|> C128-Modus, in dem die 6502-kompatiblen CPUs (C128+Floppy) mit 2Mhz
|> betrieben werden konnten

Jup, und die dem C128 auch noch zu einem 62Hz-PAL-Modus verhelfen, wie erst
vor wenigen Jahren herausgefunden wurde.

|> Ok, soll wohl eine Ausnahme gewesen sein, das Ger=E4t.

Man hat's ja auch nochmal mit dem C65 probiert.

Aber grundsätzlich war es eine Ausnahme... Bei den Sinclairs war keiner zu den
anderen kompatibel (wenn man mal von den Spectrums unter sich bzw. ZX80/81
absieht), genauso war's bei den Commodores (abgesehen vom C128) und den Apples
(abgesehen vom Apple IIGS, der eine ähnliche Totgeburt wie der C128 war).

|> F=FCr Office, Spiele, Mediaplayer, usw. hingegen macht das UI den
|> Hauptanteil der Programme aus.=20

Sicher, hier sehe ich das Problem auch nicht. Es wäre sinnlos, z.B. einen
Shell-MP3-Player laufen zu lassen, der dann per popen() z.B. die
Aussteuerungsanzeige an die GUI zurückschickt.

|> Du kannst doch auch deiner Nachbarin nicht ernsthaft das Auswendiglernen =
|> von Kommandozeilenaufrufparametern zumuten wollen.

Doch... Sie kann beim Auto ja auch erlernen, wie man selbiges betankt, startet
und den Reifendruck bzw. Ölstand überprüft. Der Ölmeßstab ist bei jedem
Fabrikat/Hersteller an einer anderen stelle, auch der Tankeinlaß ist mal links,
mal rechts, bei den Amis sogar auch mal hinter dem Nummernschild.

Komischerweise akzeptiert man beim Auto durchaus, wenn das Licht beim einen
Fabrikat als Drehschalter, beim anderen als Dreh-Hebel zu bedienen ist. Beim
Computer hingegen ist diese Varianz geradezu unerträglich, es hat immer alles
so zu sein, wie man es mal (meist unter Windows) gelernt hat.

Beim Computer hingegen ist man komischerweiser der Ansicht, daß das Ding so
wie ein Toaster zu bedienen sein muß. Immer gleich, ein Hebel, ein Stellrad.

Eben wie in dem von Oliver beschrieben Szenario.

Rainer

 

[Rainer Buchty]

In article <cu33o1$aei$1@online.de>,
Bernhard Walle <bernhard.walle@gmx.de> writes:
|> Office ja, Spiele möglicherweise, Mediaplayer mit Sicherheit nicht.
|> Genau deshalb gibt es unter Linux z. B. die xine-lib, auf der
|> unterschiedliche UIs (Xine-UI, Kaffeine, gXine, Xfmedia, etc.) aufsetzen.

Nunja. Bei Media-Playern kann ich es zumindest verstehen, wenn man Monolithen
bäckt, denn hier ist eine starke Interaktion zwischen dem nackten Algorithmus
und der Wiedergabe (respektive dem System) gegeben.

|> Ja, allerdings werden oftmals Programme geschrieben, wo GUI und
|> eigentlicher Code im Quellcode so vermengt sind, dass eine Portierung
|> auf ein anderes GUI-System einem Rewrite der kompletten Anwendung
|> gleichkommt, weil einfach keine Trennung vorhanden sind.

Danke. Dies war der Punkt, auf den ich raus wollte.

Rainer

 

[Olaf Kaluza]

Oliver Bartels <spamtrap@bartels.de> wrote:

in vielen Bereichen wegen der Einheitsarchitektur die Zeit stehen
geblieben ist.

Also an dieser Stelle haettest du unbedingt das A20-Gate erwaehnen
muessen.

Wir haben sehr gute Umsätze im Softwarebereich damit erzielt,
dass wir ein komplexes C Programm mit einer definierten
Bibliotheksschnittstelle auf diversen Plattformen an Wettbewerber
verkauft haben ;-)

Bekomme ich Rabatt wenn ich Frage wie das Programm heisst? :-]

Olaf

 

[Gerald Oppen]

Oliver Bartels schrieb:

Und stell' Dir vor: Ich kann von einer Minute auf die andere von
meinem Mopped (Gas drehen mit rechter Hand, bremsen vorne
mit rechter Hand, Schalten mit linkem Fuß usw.) auf mein Auto
(Gas mit rechtem Fuß, Schalten mit Tipptronic) oder ein anderes
mit Schaltgetriebe (Kupplung mit linkem Fuß, schalten mit der
rechten Hand, also da, wo beim Mopped das Gas ist ... )
umsteigen, ohne dass dies zu Problemen führt.

Und ganz viele andere Menschen können das auch ...

Ob da in Prozent bei den Fahrern ausgedrückt immer noch so ganz viele
sind...

Gerald

 

[Gerald Oppen]

Olaf Kaluza schrieb:

Naja, ich werd die bisher erhaltenen Tips sicherlich beruecksichtigen,
aber ich bin auch gespannt was das Arbeitsamt vorbeischickt. :-]

Da würde ich nicht all zu viel erwarten... das Arbeitsamt mag noch als
Kontaktadressenverteiler funktionieren, aber wenn die Anfangen selber
zuzuordnen wer auf welchen Arbeitsplatz passen könnte und Bäckermeister
zu einer Firma schickt die Autoradios entwickeln...

Gerald

 

[MaWin]

"Rainer Buchty" <buchty@atbode100.lrr.in.tum.de> schrieb im Newsbeitrag
news:cu3l59$39sl5$1@sunsystem5.informatik.tu-muenchen.de...

Komischerweise akzeptiert man beim Auto durchaus, wenn das Licht beim einen
Fabrikat als Drehschalter, beim anderen als Dreh-Hebel zu bedienen ist. Beim
Computer hingegen ist diese Varianz geradezu unerträglich, es hat immer alles
so zu sein, wie man es mal (meist unter Windows) gelernt hat.
Beim Computer hingegen ist man komischerweiser der Ansicht, daß das Ding so
wie ein Toaster zu bedienen sein muß. Immer gleich, ein Hebel, ein Stellrad.

Als der PC erfunden wurde, egal ob nun Altair, Apple oder IBM-PC,
freute sich die Welt, das es endlich brauchbare Rechenknechte gab,
die man als Einzelperson verstehen und bedienen konnte, und mit
denen man sinnvolle Sachen machen konnte (Spiele...
ohne das man ein ganzes Heer von Systemadministratoren brauchte,
jahrelange Schulung, und einem dutzende Hindernisse in den Weg
gelegt wurden, wie es auf Grossrechnern ueblich war.

Die Zeit ist lange vorbei, jeder PC heute laesst ehemalige Big
Irons locker hinter sich, was Komplexitaet, Unbedienbarkeit und
Unzuverlaessigkeit anlangt. Selbst ein Heer von 'Fachleuten' ist
heute oft nicht mehr in der Lage, herauszufinden, WARUM auf einem PC
etwas nicht funktioniert. Dokumentiert ist der ganze Verhau sowieso
schon lange nicht mehr (Linux mal aussen vor).

Die gesteigerte Komplexitaet war dummerweise im wesentlichen Selbstzweck,
d.h. es gibt aus Anwendersicht KEINEN Grund fuer die ca. 100000
Dateien auf beispielsweise meinem Rechner. Die sind im wesentlichen da
wegen konzeptioneller Fehler von M$.
Aus Anwendersicht tut es (vereinfacht gesagt) SYSTEM.EXE, BROWSER.EXE,
DRUCKER.DRV, TCPIP.DRV und ein paar Font und Konfigurationsdateien.

Ich habe damals verstanden, warum meine Eltern den Videorecorder nicht
bedienen konnten, ich verstehe heute Leute, die vor dem Computer
verzweifeln, und frage mich, welches kranke Hirn meine Handysoftware
entworfen hat.

Ebenso, wie ein Redakteur kaum glauben kann, das viele seiner Leser
klueger sind als er, oder ein Stiftung-Warentest-Mensch nicht begreift,
das viele Kunden mehr Ahnung von der getesteten Materie haben als er,
ignorieren viele Softwareentwickler, das der Mensch, der vor dem
Computer ueber sie schimpft, RECHT hat.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[MaWin]

"Rainer Buchty" <buchty@atbode100.lrr.in.tum.de> schrieb im Newsbeitrag
news:cu2vfm$39jc5$1@sunsystem5.informatik.tu-muenchen.de...

Dann erklär mal.

Von allen GUIs (X, Mac, GEM, AmigaOS, NeXT, BeOS, ....)
ist Windows mit Abstand am programmiererfreundlichsten.
Mit grossem Abstand.

Das Win3.1 API (weitestgehend identisch mit Win 1.0) ist
ein Lehrmeisterstueck fuer eine sinnvolle und tragfaehige
Funktionensammlung.

Eine Applikation teilt sich normalerweise NICHT in eine
Oberflaeche und einen Rechenkern, sondern in 3 Dinge:
Oberflaeche <-> Datenstruktur <-> Rechenkern
und die Datenstruktur hat natuerlich ebenfalls viele
Funktionen (Daten laden/speichern).

Trennt man Oberflaeche von Datenstruktur durch ein zu loses
Interface, wird die Performance schlecht und man sieht es
der Applikation auch meist an, weil die Oberflaeche zu wenig
Interaktion bietet.

Trennt man Datenstruktur und Rechenkern, sinkt auch die
Performance und wird ein Programm meist aufwaendig und
damit unuebersichtlich programmiert und fehlerhaft.

Man muss vor der Programmerstellung keine kuenstliche Trennung
zwischen Rechenkern und Oberflaeche machen. Man muss nur logisch
nach realen Gegebenheiten programmieren. Denn wenn in der
Realitaet das Rechnen ohne Benutzerinteraktion erfolgt, kann
man zu jeder Zeit Rechenkern von Oberflaeche trennen. Falls das
Programm nicht durch kranke Hirne sondern durch logisch denkende
Menschen mit geringstem Aufwand programmiert wurde, spiegelt es
naemlich die Realitaet wider, haben also Oberflaeche und Rechenkern
keine programmtechnischen Abhaengigkeiten. Beide sind aber direkt
abhaenigig von der Datenstruktur.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Kurt Harders]

Hallo MaWin,

MaWin wrote:

Von allen GUIs (X, Mac, GEM, AmigaOS, NeXT, BeOS, ....)
ist Windows mit Abstand am programmiererfreundlichsten.
Mit grossem Abstand.

Nein, X ist deutlich konsistenter und leichter erlernbar. Ausserdem hat
das Wissen über X eine größere Transferierbarkeit.

Eine Applikation teilt sich normalerweise NICHT in eine
Oberflaeche und einen Rechenkern, sondern in 3 Dinge:
Oberflaeche <-> Datenstruktur <-> Rechenkern
und die Datenstruktur hat natuerlich ebenfalls viele
Funktionen (Daten laden/speichern).

Ist OO an Dir vorbeigegangen? Die Datenstruktur gehört heute mit zur
Logik/Verarbeitung, weil sie Bestandteil der verwendeten Objekte ist.
Das gilt bis hin zur Persistenzschicht.

Trennt man Oberflaeche von Datenstruktur durch ein zu loses
Interface, wird die Performance schlecht und man sieht es
der Applikation auch meist an, weil die Oberflaeche zu wenig
Interaktion bietet.

Trennt man Datenstruktur und Rechenkern, sinkt auch die
Performance und wird ein Programm meist aufwaendig und
damit unuebersichtlich programmiert und fehlerhaft.

Genau deswegen ist OO von Vorteil, es trennt nicht Daten von der
Verarbeitung und bietet effiziente und wohldefinierte Schnittstellen zu
den Objekten.

Gruß, Kurt
--
Kurt Harders
MBTronik - PiN - Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.mbtronik.de

 

[Rafael Deliano]

Da würde ich nicht all zu viel erwarten...
Die lassen halt jetzt die Meute los all derer die sich bewerben

müssen um als arbeitswillig gelten zu dürfen.
Aus dem Grund sind Stellenanzeigen in Zeitungen auch keine
gute Alternative mehr: allgemeiner Ansturm. Also schalten Firmen
"Personaldienstleister" vor. Die zeichnen sich durch völlige
Ahnungslosigkeit bezüglich der Gegebenheiten in der Firma des
Auftraggebers und bezüglich tatsächlicher fachlicher Eignung des
Bewerbers aus. Reduziert sich dann auf das Abhaken ob Begriffe
die in der Anzeige standen auch im Bewerbungsschreiben wieder
zu finden sind. Einzige Ausnahme könnten Vermittler sein die auf
E-Technik spezialisiert sind, vgl. die die öfter in M&T auftauchen.
Und dann gibts noch die oberschlauen Firmen die den Ansturm
mildern wollen indem sie einfach das Anforderungsprofil beliebig
auf Typ Supermann aufblähen. Die kriegen dann die Bewerbungschreiben
die genauso schief optimiert wurden und sind dann passend bedient.

MfG JRD

 

[MaWin]

"Kurt Harders" <news@kurt-harders.de> schrieb im Newsbeitrag
news:36m6f9F50hv9sU1@individual.net...

Es gleitet zu sehr ins Programmieren ab, daher egal was du
antwortest meine letze Mail zum Thema.

Nein, X ist deutlich konsistenter und leichter erlernbar.

Ein klares Nein. Bedenke, das es fuer X nicht mal allgemein
akzeptierte Dialoggadgets gibt (Motif, KDE, ...)
Und selbst wenn WinAPI den Eindruck erweckt, das anzeigender
Rechner und rechnender Recher dieselbe Maschine sein muessen:
Nein, auch das WinAPI ist so gestrickt, das eine Trennung
zwischen Displayrechner und anwendungsausfuehrendem Rechner
bedacht worden war (erkennbar z.B. an HBITMAP-Funktionen).

Ausserdem hat das Wissen über X eine größere Transferierbarkeit.

Von Unix zu Unix zu Unix ? Wow. Das Windows-API ist *sogar* unter

Unix verfuegbar, DAS nenne ich portabel, Wines sei Dank. Sogar GEM
war von TOS zu DOS bis zu Unix und Helios verfuegbar, also viel
weiter transferierbares Wissen.

Ist OO an Dir vorbeigegangen? Die Datenstruktur gehört heute mit zur
Logik/Verarbeitung, weil sie Bestandteil der verwendeten Objekte ist.
Das gilt bis hin zur Persistenzschicht.

Genau deswegen ist OO von Vorteil, es trennt nicht Daten von der
Verarbeitung und bietet effiziente und wohldefinierte Schnittstellen zu
den Objekten.


Ein Fehler vieler heutige Programme. Nach dieser Strukturierung

ergibt sich ein kein vertikal teilbares Programm

+------+-----+------+
| | | |
|Ober- |Daten|Rechen|
|fläche| |-kern |
| | | |
+------+-----+------+

sondern das Programm ist ein unteilbarer monolithischer Block,
der bloederweise nur horizontal teilbar ist

+-----------------------------------+
| vermengtes Durcheinander |
+-----------------------------------+
|spezialisierte Sonderkonstruktionen|
+-----------------------------------+
| simple Elementfunktionen |
+-----------------------------------+

das ist durchaus das inzwischen bekannte Drama der OO-Technologie.
Denn eine auf beide Arten teilbare Programmstruktur

+------+-----+------+
| Zusammenfassendes |
+------+-----+------+
|Ober- |Daten|Rechen|anwendungsgerechtes
|fläche| |-kern |API
+------+-----+------+
| | | |simple
| | | |Elementfunktionen
+------+-----+------+

uebersteigt erwiesenermassen die Planungsfaehigkeit realer Programmierer.

Viele OO Buecher beginnen mit der Bemerkung, das OO die Realitaet
abbildet. In der Realitaet sind Objekte(Gegenstaende) aber von
der sie bearbeitenden Werkstatt(Verarbeitung) getrennt. Ein Radio
schleppt die R%F-Werkstatt NICHT mit sich herum, daher kann eine
R&F-Werkstatt auch Fernseher reparieren, sogar Computerbildschirme.
Auch weiss ein Radio NICHT, wie es sich in ein Regal stellt, es
passt in viele Regale, sogar in welche, die zur Zeit des Radios
noch nicht erfunden waren. Ein kleiner Blick auf die Realitaet
zeigt, was derzeit an vielen OO-Programmen falsch ist. Das Problem
ist aber inzwischen bekannt. Ich habe Smalltalk bereits 1986 wegen
Unbrauchbarkeit zur Applikationsprogrammierung bei Seite gelegt.

Die Realitaet trennt Daten und Verarbeitung, sie arbeitet eben nicht
dokumentenzentrisch (wenn ich ein Papier habe, stehen mir eben nicht
saemtliche Werkzeuge zum Schreiben, Bemalung, Zerschneiden automatisch
zur Verfuegung, wie jeder weiss dem mal eine Offsetdruckmaschine fehlte),
sondern liefert Werkzeuge (Anwendungsprogramme) zur Bearbeitung,
ist also Applikationsorientiert. Sorry, so ist die Realitaet, egal
was in OO-Buechern an modernen Maerchen drin steht.
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Bernhard Walle]

Hallo,

* Rainer Buchty [06.02.2005 00:36]:

In article <cu33o1$aei$1@online.de>,
Bernhard Walle <bernhard.walle@gmx.de> writes:
|> Office ja, Spiele möglicherweise, Mediaplayer mit Sicherheit nicht.
|> Genau deshalb gibt es unter Linux z. B. die xine-lib, auf der
|> unterschiedliche UIs (Xine-UI, Kaffeine, gXine, Xfmedia, etc.) aufsetzen.

Nunja. Bei Media-Playern kann ich es zumindest verstehen, wenn man Monolithen
bäckt, denn hier ist eine starke Interaktion zwischen dem nackten Algorithmus
und der Wiedergabe (respektive dem System) gegeben.

Dafür gibt es Shared Libraries. Es findet auch eine sehr starke
Interaktion zwischen der C-Library und dem Programm statt, deshalb linkt
man auch nicht bei jedem Programm die C-Library statisch hinzu.

Natürlich macht ein extra Kommandozeilenprogramm, das man aufruft und
mit den Daten füttert, hier keinen Sinn.


Gruß,
Bernhard

 

[Axel Schwenke]

"MaWin" <me@private.net> wrote:

"Rainer Buchty" <buchty@atbode100.lrr.in.tum.de> schrieb

p2c

Jemals ausprobiert mit einem ernsthaften Programm ?
Eindeutig nicht.

Es gibt keine ernsthaften P Programme. Zumindest keine, die man
portieren wöllte. Bzw. wo man nicht schon vorher weiß, daß die
Portierung fehlschlagen *muß*. GUI-Krempel halt.

OK, erste C-Versionen von TeX wurden wohl per p2c portiert. Später
hat man dann 'web' auf 'web2c' aufgebohrt und das funktioniert auch.

sinnvolles Sicherheitskonzept

Falsch. Es gibt KEINEN Grund, derartiger Altsoftware, wenn
sie direkte Zugriffe macht, diese nicht zu erlauben, so lange
die Resource frei ist.

Die Entscheidung, ob eine Resource frei ist, trifft in richtigen
Betriebssystemen der Betriebssystemkern. Deswegen ist es eine
ausgesprochen blöde Idee, eben diesen Kern zu umgehen.


XL

 

[Matthias Weingart]

Oliver Bartels <spamtrap@bartels.de> wrote in
news:k04a01hp1roegoqdltfon253gjoc1fdsl7@4ax.com:

Auch alle mit älteren Visual C geschriebene Programme würden nicht
mehr funktionieren (und das sind eigentlich fast alle). Letztlich
benutzte Delphi auch nur die gleichen Schnittstellen.
Jein, das Zeug installiert tonnenweise Spezial-DLL's.
Wenn die aus marktpolitischen Gründen ausgehebelt werden
sollen, geht das ganz einfach. Bisher war Borland halt nur
nicht in der Hauptschußlinie.

Delphi braucht nur dann Spezial-DLL's, wenn es so eingestellt ist.
Man kann das aber auch "statisch linken", so dass zwar die Exe um
300kBytes groesser wird, aber _keine_ zusätzlichen Dll's usw.
im System benötigt werden. (ein grosser Vorteil gegenüber z.B.
VisualBasic).

M.
--
Bitte auf mwnews2@pentax.boerde.de antworten.

 

[MaWin]

"Axel Schwenke" <axel.schwenke@gmx.de> schrieb im Newsbeitrag
news:1it4uc.kp2.ln@idefix.xl.local...

Es gibt keine ernsthaften P Programme. Zumindest keine, die man
portieren wöllte. Bzw. wo man nicht schon vorher weiß, daß die
Portierung fehlschlagen *muß*. GUI-Krempel halt.

Ich haette da zumindest eins gehabt, an dem p2c aber grandios

gescheitert ist, OBWOHL das Programm ebenso uralt wie p2c ist.

Die Entscheidung, ob eine Resource frei ist, trifft in richtigen
Betriebssystemen der Betriebssystemkern. Deswegen ist es eine
ausgesprochen blöde Idee, eben diesen Kern zu umgehen.

Bloss weil du und Microsoft nicht weiss, wie man das Problem richtig
loest, heisst das noch lange nicht, das es keine Loesung gibt.
Warum FOLGST du nicht den extra schon gegebenen Hinweisen und liest
was schon geschrieben wurde, sondern postest in Unkenntnis ?
--
Manfred Winterhoff, reply-to invalid, use mawin at despammed.com
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

 

[Rainer Buchty]

In article <36lbiiF53i1nmU1@individual.net>,
"MaWin" <me@private.net> writes:
|> Die gesteigerte Komplexitaet war dummerweise im wesentlichen Selbstzweck,
|> d.h. es gibt aus Anwendersicht KEINEN Grund fuer die ca. 100000
|> Dateien auf beispielsweise meinem Rechner.

Mmhm, ich kenne das 50%-Mirakel... Egal, wie groß die Festplatte ist,
direkt nach Installation derselben ist sie quasi unmittelbar zu 50% gefüllt.

|> Ich habe damals verstanden, warum meine Eltern den Videorecorder nicht
|> bedienen konnten

Nein, hier muß ich widersprechen.

Es gab auf dem Kassettenrekorder das |> Play-Symbol, es gab auf dem
CD-Player das |> Play-Symbol und es gab auf dem Videorekorder das |> Play-
Symbol.

Trotzdem wurde man für jedes Gerät wieder aufs neue gefragt, wie man denn
hier nun die Abspielfunktion aktiviert.

Programmieren, ja, das war -- abgesehen von Grundig mit Textprogramming --
immer eine Wissenschaft für sich.

|> Ebenso [...] ignorieren viele Softwareentwickler, das der Mensch, der
|> vor dem Computer ueber sie schimpft, RECHT hat.

Sicherlich ist das Programmieren kein Selbstzweck (so wie früher, als die
Lösung im Vordergrund stand), aber andererseits ist dem Anwender IMO durchaus
zuzumuten, sich von Zeit zu Zeit an eine veränderte Bedienung zu gewöhnen.

Die schluckt er aber nur, wenn sie aus Redmond kommt. In allen anderen Fällen
wäre die Lernkurve unzumutbar steil.

Rainer