Verwirrung in Programiersprachen!Wer schaft mir Klartext?
-
Gröhler schrieb:
Nein, es ist noch lange nicht sonnvoll, solange man es nur für sich für sinnvoll erachtet. Der Witz ist, das es auch sowas wie Projekte gibt, die in Teamarbeit gelöst werden müssen. Und dann ist die einzige egomanische Sichtweise nur noch für den A-Punkt! Genau deshalb sind Namen auf den ersten Blick Schall und Rauch. Beim zweiten Blick, muß ich dann doch wieder einen sinnvollen Namen "designen" damit ihn jeder versteht, der im Team dabei ist oder später mal das Zeug pflegen muß.
vielleicht, aber auch das hängt vom einzelnen ab, wie gut er mit gegebenen umständen umgehen kann. ein vielseitiger programmierer kann mit lexical_cast, so wie mit funktionen der crt/libc umgehen und weiß wie er seine schnittstellen entsprechend anzupassen hat.
Gröhler schrieb:
Ihr arbeitet wohl nur an Einmann-Projekten, die anscheinend nur von kurzer Lebensdauer sind. Aber geht mal an ein Projekt mit mehreren Leuten das mehr als ein Jahrzehnt gepflegt wird. Dann wollen wir mal weiter sehen, wie weit ihr mit eurer Ego-Perspektive kommt.
unterstellungen, über die wir ja wohl nicht weiter diskutieren zu brauchen.
Gröhler schrieb:
lexical_cast ist schon eine sehr aussagefähige Sache, der Template-Parameter gibt den Rest für ein besseres Verständnis.
das hat hier nie jemand bestritten.
-
Gröhler schrieb:
Nein, es ist noch lange nicht sonnvoll, solange man es nur für sich für sinnvoll erachtet. Der Witz ist, das es auch sowas wie Projekte gibt, die in Teamarbeit gelöst werden müssen.
Und das heißt automatisch, dass man boost benutzen muss? Ich würd mich totlachen, wenns nicht so traurig wär. Der Witz ist, dass es auch Projekte gibt, in denen man einer von vielen ist und nicht mal einfach so irgendeine tolle Lib einbinden kann, nur um einen tollen Cast zu haben, den n-1 Teammitglieder noch nie gesehen haben. atof dagegen kennt jeder.
Ihr arbeitet wohl nur an Einmann-Projekten, die anscheinend nur von kurzer Lebensdauer sind. Aber geht mal an ein Projekt mit mehreren Leuten das mehr als ein Jahrzehnt gepflegt wird. Dann wollen wir mal weiter sehen, wie weit ihr mit eurer Ego-Perspektive kommt.
BTDT.
-
sothis_ schrieb:
ja, omfgwtfbbq. genau das ist es was ich hasse. wenn der programmierer etwas als problematisch ansieht, weil es seine fehler nicht automatisch erkennt, ist es gleich schlecht und unverständlich(!) - lol. diese einstellung hat programmiersprachen wie c# hervorgebracht und ein generation von c#-kiddies, wie sie ihres gleichen sucht. jetzt schimpft sich jeder softwareentwickler, der ein fenster mit schaltern zusammengeklickt hat, mit ein paar fremdwörtern um sich schmeißt, aber überhaupt nicht mehr versteht, wie die maschine auf der alles läuft überhaupt funktioniert. ich persönlich halte das für eine alarmierende entwicklung.
wieso alarmierend? nicht jeder muss alles können und wissen. z.b. ein programmierknecht für visual-bräsig, c#, php, etc. braucht keine assembler-kenntnisse, weil sowas in seinem aufgabenbereich nie dran vorkommt.
demzufolge haben die auch luxuriöse ansprüche wie z.b. eine programmiersprache, die gewisse fehler erst gar nicht zulässt, eine laufzeitumgebung die fehlertolerant ist und grobe fehler abfängt ohne dass das system abschmiert, riesige standardbibliotheken, die einem alles abnehmen, usw. kann man zwar drüber lästern, aber das zeug hat seine berechtigung. auch weil es die wirtschaft gut anfeuert, ganze industrien und neue berufszweige gschaffen hat usw.
-
fricky schrieb:
sothis_ schrieb:
ja, omfgwtfbbq. genau das ist es was ich hasse. wenn der programmierer etwas als problematisch ansieht, weil es seine fehler nicht automatisch erkennt, ist es gleich schlecht und unverständlich(!) - lol. diese einstellung hat programmiersprachen wie c# hervorgebracht und ein generation von c#-kiddies, wie sie ihres gleichen sucht. jetzt schimpft sich jeder softwareentwickler, der ein fenster mit schaltern zusammengeklickt hat, mit ein paar fremdwörtern um sich schmeißt, aber überhaupt nicht mehr versteht, wie die maschine auf der alles läuft überhaupt funktioniert. ich persönlich halte das für eine alarmierende entwicklung.
wieso alarmierend? nicht jeder muss alles können und wissen. z.b. ein programmierknecht für visual-bräsig, c#, php, etc. braucht keine assembler-kenntnisse, weil sowas in seinem aufgabenbereich nie dran vorkommt.
demzufolge haben die auch luxuriöse ansprüche wie z.b. eine programmiersprache, die gewisse fehler erst gar nicht zulässt, eine laufzeitumgebung die fehlertolerant ist und grobe fehler abfängt ohne dass das system abschmiert, riesige standardbibliotheken, die einem alles abnehmen, usw. kann man zwar drüber lästern, aber das zeug hat seine berechtigung. auch weil es die wirtschaft gut anfeuert, ganze industrien und neue berufszweige gschaffen hat usw.
auch das stimmt, aber ich persönlich bezweifle, das dies zukünftig der qualität von software zugute kommt. zudem hardwarehersteller sich mehr und mehr and den status quo heutiger softwareschittstellen richten. schau dir an, was aus der x86 architektur geworden ist. erweiterungen über erweiterungen, nicht um abwärtskompatibilität zu gewährleisten, sondern um zu verhindern das grundlegende änderungen am betriebssystem notwendig wären. neue architekturen verkaufen sich einfach nicht, schau dir die intel itanium architektur an. im umkehrschluss interessieren sich zunehmend immer weniger für systemprogrammierung, da es auch nicht notwendig erscheint. also konzentrieren sich mehr und mehr auf abstraktion und noch mehr abstraktion, aber eigentliche innovationen im softwarebereich bleiben aus. ich sehe da eine deutliche verschiebung des wissenskapitals, und denke das deswegen softwarequalität und innovationsquantität so langsam aber sicher stagniert.
edit: oh sorry, ich wollte den thread nicht so derart offtopic schieben
-
sothis_ schrieb:
schau dir an, was aus der x86 architektur geworden ist. erweiterungen über erweiterungen, nicht um abwärtskompatibilität zu gewährleisten, sondern um zu verhindern das grundlegende änderungen am betriebssystem notwendig wären.
klar, x86er-systeme sind übelstes flickwerk. das fing ja schon an, als sie den 8086-adressbus aufgebohrt haben.
sothis_ schrieb:
neue architekturen verkaufen sich einfach nicht, schau dir die intel itanium architektur an. im umkehrschluss interessieren sich zunehmend immer weniger für systemprogrammierung, da es auch nicht notwendig erscheint.
nicht im pc-bereich, aber sonst schon. es gibt prozessoren für alle anwendungsfälle, die sich gut verkaufen. tendenz steigend, siehe z.b. hier: http://www.esacademy.com/automation/faq/primer/3.htm
und dafür braucht man auch programmierer, die noch mit bits und bytes 'per du' sind. tendenz ebenfalls steigend. die leute, die sich für systemprogrammierung interessieren, fangen heute bloss anders an, als damals. damals musste ja jeder, um seiner kiste speed zu entlocken, in assembler coden und wurde zwangsweise zum low-level freak.sothis_ schrieb:
also konzentrieren sich mehr und mehr auf abstraktion und noch mehr abstraktion, aber eigentliche innovationen im softwarebereich bleiben aus
naja, heute fummeln sich sich die 'great game coder' was mit c++, directx und boost hin, alles zig-fach hinter abstraction layern versteckt. das programm ist dann zwar etliche megabytes gross, frisst taktzyklen ohne ende aber tuts trotzdem ausreichend gut, weil die hardware so viel power hat. trotzdem gibts auch auf'm highlevel-sektor innovationen. vielleicht weniger bei den c++-fummlern, die schon seit jahren auf ihren neuen standard warten, aber z.b. im web-bereich gibts ja seit je her ständig neue ideen.
-
sothis_ schrieb:
wieder eines dieser neumodischen fremdwörter
sinnvoll ist das, was jeder für sich selbst als sinnvoll erachtet. übrigens kann float unter umständen gleich breit wie double sein, von daher mach deine namensbashing argumentation keinen sinn also gibt es keinen unterschied zwischen float und double. gut, wieder was gelernt.
-
Shade Of Mine schrieb:
sothis_ schrieb:
wieder eines dieser neumodischen fremdwörter
sinnvoll ist das, was jeder für sich selbst als sinnvoll erachtet. übrigens kann float unter umständen gleich breit wie double sein, von daher mach deine namensbashing argumentation keinen sinn also gibt es keinen unterschied zwischen float und double. gut, wieder was gelernt.
pauschalisierende aussagen obwohl ich
sothis_ schrieb:
unter umständen
schrieb.
Die Implementation muß sicherstellen, daß double größer oder gleich float ist und long double größer oder gleich double (bezogen auf Wertebereich und Genauigkeit). Tatsächlich sind long double und double oft das selbe.
-
fricky schrieb:
klar, x86er-systeme sind übelstes flickwerk. das fing ja schon an, als sie den 8086-adressbus aufgebohrt haben.
in der tat
fricky schrieb:
nicht im pc-bereich, aber sonst schon. es gibt prozessoren für alle anwendungsfälle, die sich gut verkaufen. tendenz steigend, siehe z.b. hier: http://www.esacademy.com/automation/faq/primer/3.htm
und dafür braucht man auch programmierer, die noch mit bits und bytes 'per du' sind. tendenz ebenfalls steigend. die leute, die sich für systemprogrammierung interessieren, fangen heute bloss anders an, als damals. damals musste ja jeder, um seiner kiste speed zu entlocken, in assembler coden und wurde zwangsweise zum low-level freak.stimmt, der mikrocontrollermarkt bildet da derzeit wohl eine ausnahme. aber selbst da wird mir manchmal angst und bange, wenn überlegungen angestellt werden, wie man die denn am besten mit c++ programmieren könnte. nicht dass es sonderlich schlimm wäre, aber auch hier könnte ein versteifen auf hardwarearchitekturen stattfinden, wenn man mehr und mehr abstraktion in der softwareschicht einführt. derzeit ist das alles noch sehr lebendig, und ich hoffe das dies im mikrocontrollerbereich so bleibt.
fricky schrieb:
naja, heute fummeln sich sich die 'great game coder' was mit c++, directx und boost hin, alles zig-fach hinter abstraction layern versteckt. das programm ist dann zwar etliche megabytes gross, frisst taktzyklen ohne ende aber tuts trotzdem ausreichend gut, weil die hardware so viel power hat. trotzdem gibts auch auf'm highlevel-sektor innovationen. vielleicht weniger bei den c++-fummlern, die schon seit jahren auf ihren neuen standard warten, aber z.b. im web-bereich gibts ja seit je her ständig neue ideen.
das problem hier ist leider auch die kommerzialisierung des softwaremarktes in den 80ern. damit wurde zeit in der tat zu geld. man kann sich heute leider nicht mehr monate zeit nehmen um das übelst geile spiel zu entwickeln in dem man via assembler oder C GPU's direkt programmiert (wenn denn die spezifikationen frei verfügbar wären, auch daran hat microsoft mit ihrem treibermodell ein wenig schuld). ich bin mir sicher man könnte so wesentlich mehr aus derzeitiger hardware herausholen als wie es die heutige programm-grafikapi-windowsschittstelle-treiber-bios-hardware methode tut. es dauert einfach zu lang und bringt kein geld. noch dazu das ich persönlich auch keine lust hätte ein solches mammutprojekt überhaupt erst anzufangen, was in diesem falle vielleicht nicht am fehlenden wissen liegt, mehr aber an der fehlenden motivation - geld. nunja, mal sehen was die zukunft so bringt
-
sothis_ schrieb:
pauschalisierende aussagen
ich dachte du lernst vielleicht wenn ich etwas überzeichne.
float und double sind unterschiedliche datentypen. dass es atof heisst anstatt atod oder atofl ist einfach ein design fehler. es ist kein showstopper, aber ein fehler in der library. ähnlich die das inkonistente d und lf für double.hindert einen das daran gute programme zu schreiben? nein.
ist es ein designfehler? ja.warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
-
Beantworte erst mal Shades Frage, bevor du mit weiteren Haarspaltereien kommst.
-
Shade Of Mine schrieb:
...
warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
Was an std::string ist ein Designfehler? :o
-
Zeus schrieb:
Shade Of Mine schrieb:
...
warum ist das so schwer zu aktzeptieren. std::string ist auch ein designfehler. Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
Was an std::string ist ein Designfehler? :o
Alles.
Genauer: dass std::string mutable ist.
Noch genauer: alles.
-
Shade Of Mine schrieb:
Fast überall sieht man sie - warum kann man sie dann nicht aktzeptieren?
das verstehe ich jetzt nicht :S. ich akzeptiere sie doch, ich schreibe damit programme ohne mir gedanken darüber zu machen, ob es jetzt schlechtes design ist oder nicht. vieles rührt eben noch aus der vergangenheit, in der atof() eben noch kein double zurückgegeben hat. es stört mich persönlich nicht im geringsten ob es nun atof() oder atod() oder stringtofloatingpointnumberwith64bitprecision() heißt, da ich mich entweder damit arrangiert habe, der compiler mich warnt das etwas mit dem rückgabetyp nicht stimmt oder es eindeutig aus der referenzdokumentation hervorgeht.
-
sothis_ schrieb:
fricky schrieb:
nicht im pc-bereich, aber sonst schon. es gibt prozessoren für alle anwendungsfälle, die sich gut verkaufen. tendenz steigend, siehe z.b. hier: http://www.esacademy.com/automation/faq/primer/3.htm
und dafür braucht man auch programmierer, die noch mit bits und bytes 'per du' sind. tendenz ebenfalls steigend. die leute, die sich für systemprogrammierung interessieren, fangen heute bloss anders an, als damals. damals musste ja jeder, um seiner kiste speed zu entlocken, in assembler coden und wurde zwangsweise zum low-level freak.stimmt, der mikrocontrollermarkt bildet da derzeit wohl eine ausnahme. aber selbst da wird mir manchmal angst und bange, wenn überlegungen angestellt werden, wie man die denn am besten mit c++ programmieren könnte.
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat, dann irgendwann gemerkt hat, dass es vorn und hinten hakelt, schliesslich immer mehr zu C zurückgekehrt ist und am schluss ein übler salat aus C und C++ herauskam. zum glück fallen nicht all zu viele embedded-leute auf stroustrups schöne worte rein (z.b. embeddedc++, ein c++ subset, der speziell für µC entwickelt wurde, fristet ein relativ unbeachtetes schattendasein).
sothis_ schrieb:
nicht dass es sonderlich schlimm wäre, aber auch hier könnte ein versteifen auf hardwarearchitekturen stattfinden, wenn man mehr und mehr abstraktion in der softwareschicht einführt.
das gibts da auch, aber geht nur über wenige generationen. etwa im kampf um kunden und marktanteile bohren die hersteller ihre chips immer weiter auf. aber sind die verkaufszahlen rückläufig, dann werden die dinger innerhalb kürzester zeit abgekündigt. da kennen sie nix. die meistens hersteller sind ohnehin mit einer vielzahl von architekturen parallel im markt vertreten. aber im unterschied zur PC-welt, gibts bei den µCs keinen mächtigen softwaregiganten wie m$, der den hardwareherstellern das messer an die kehle hält, sondern es ist umgekehrt. die toolhersteller kommen kaum damit hinterher, compiler etc. für neue prozessoren zu entwickeln. softwareanbieter etwa, die z.b. libraries verkaufen, müssen nicht, wie PC-softwareanbieter, nur für linux und windows, sondern für eine matrix aus prozessortyp*entwicklungsumgebung ihr zeug anbieten
-
sothis_ schrieb:
das verstehe ich jetzt nicht :S. ich akzeptiere sie doch, ich schreibe damit programme ohne mir gedanken darüber zu machen, ob es jetzt schlechtes design ist oder nicht.
nein, du aktzepierst es nicht du ignorierst es.
deshalb gefallen dir bessere lösungen nicht - weil du die fehler der vorhandenen nicht siehst.
-
fricky schrieb:
jo, ich hab schon projekte gesehen, wo man im C++ -abstraktionswahn µC-projekte angefangen hat, dann irgendwann gemerkt hat, dass es vorn und hinten hakelt, schliesslich immer mehr zu C zurückgekehrt ist und am schluss ein übler salat aus C und C++ herauskam. zum glück fallen nicht all zu viele embedded-leute auf stroustrups schöne worte rein (z.b. embeddedc++, ein c++ subset, der speziell für µC entwickelt wurde, fristet ein relativ unbeachtetes schattendasein).
ich meine es sollte durchaus alternativen zu C und assembler im embedded bereich geben, das kann nicht schaden. aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
fricky schrieb:
aber im unterschied zur PC-welt, gibts bei den µCs keinen mächtigen softwaregiganten wie m$, der den hardwareherstellern das messer an die kehle hält, sondern es ist umgekehrt. die toolhersteller kommen kaum damit hinterher, compiler etc. für neue prozessoren zu entwickeln. softwareanbieter etwa, die z.b. libraries verkaufen, müssen nicht, wie PC-softwareanbieter, nur für linux und windows, sondern für eine matrix aus prozessortyp*entwicklungsumgebung ihr zeug anbieten
stimmt, und ich hoffe das bleibt auch so, da viele sich dann eher genötigt fühlen auf frei verfügbare varianten zurückzugreifen, insbesondere was die compiler angeht
-
Shade Of Mine schrieb:
nein, du aktzepierst es nicht du ignorierst es.
nein, ich arrangiere mich damit.
Shade Of Mine schrieb:
deshalb gefallen dir bessere lösungen nicht - weil du die fehler der vorhandenen nicht siehst.
das ist eine unterstellung. korrigiere mich, wenn ich falsch liege, aber ich habe an keiner stelle dieser diskussion angemerkt, dass mir andere lösungen nicht gefallen, insbesondere weil ich fehler nicht erkenne. wenn du persönlich werden willst, da du jetzt ja schon unterstellungen vom stapel lässt, dann können wir das auch gerne per email klären.
-
sothis_ schrieb:
vielleicht sehe ich es auch zu steif aus der meiner sicht. wenn man lange mit standard-c bibliotheken programmiert, ist ein atoi() eben genau so selbstverständlich, wie ein if-else-konstrukt oder switch-block. man sieht sofort was es macht, und, wenn man sich die mühe macht auch den quellcode der crt/libc zu analysieren, wie es dies macht. von daher ist es für mich eben genau so verständlich, wie für dich ein lexical_cast.
danke
alleine das konzept eines atoi ist für konvertierungen ungeeignet. klar funktioniert es, aber es hat eine menge probleme...
-
sothis_ schrieb:
...aber objektorientierung hat im lowlevel sektor, gar nichts, aber auch rein gar nichts verloren, zumindest nicht auf heutigen prozessorarchitekturen
das würde ich nicht sagen. oop und lowlevel sind durchaus kein widerspruch. nur darfs nicht so wie C++ sein, mit seinen versteckten fussangeln, performance-bremsen und speicherfress-mechanismen. z.b. sind hardware-beschreibungssprachen wie vhdl schon so ziemlich objektorientiert, können kapselung in entities, funktionsüberladung usw.
fricky schrieb:
...da viele sich dann eher genötigt fühlen auf frei verfügbare varianten zurückzugreifen, insbesondere was die compiler angeht
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
-
fricky schrieb:
leider sind die embedded-gcc's nicht annähernd so gut, wie die für die grossen systeme.
Du hast sie ja alle schon getestet, gelle?
