Ich schaue mich gerne um was es neues alternatives gibt und weder C oder C++ konnten mich überzeugen. Offenbar kann diese Sprache wieder richtig "Spaß" machen. Bsic, Pascal/Delphi, Swift so würde es für mich passend aussehen. C hat einem ziemlich den Spaß verdorben Der Pascal/Delphi Vergleich bezieht sich auf aktuelle Versionen nicht au die Urzeiten aus den 78-90er Jahre! SWIFT gibt es mittlerweile auch für Windows. Ich sehe sehr viele Parallelen zu Pascal/Delphi- Alles was hier von vielen bei C als Vorteil angepriesen wird, ist bei Swift rausgeworfen/gemieden worden wie bei Pascal auch. http://www.swiftkurs.de/der-zuweisungsoperator/ Apple selbst stellt seine eigenen Anwendungen auf Swift um, dadurch sollte die Sprache langsam auch verlässlich für Entwicklungen taugen https://www.heise.de/mac-and-i/meldung/Swift-Apple-stellt-zahlreiche-Apps-auf-neue-Programmiersprache-um-4543449.html Ebenfalls gibt es vernünftige Entwicklngstools für Swift. Ich denke diese Sprache daher tatsächlich ernstzunehmende Konkurrenz für C++ werden könnte auch auf lange Sicht im Embedded >bereich und freue mich darüber, da ich, wie gesagt, den Hype um C bzw C++ nicht verstehen kann https://www.makeuseof.com/tag/program-swift-in-windows/ Da der swift Code offen ist, wird es evtl auch bald eine richtige Windowsumsetzung geben?
:
Nun ja, Google hat Go, Microsoft C#, Mozilla Rust und Apple hat jetzt Swift und muss sich nicht mehr Objective-C borgen. Jedem seine eigene Programmiersprache, wo er nach belieben dran rumstricken kann, ohne dass einer dazwischenfunkt.
Gegeg J. schrieb: > den Hype um C bzw C++ nicht verstehen Naja Hype finde ich jetzt sehr übertrieben. C hat an die 50 Jahre auf dem Buckel, C++ mehr als 30. Da kann man nicht wirklich von einen neumodischen Hype sprechen. Eher von einem Industriestandard ;-). C ist hat C. Für viele hardwarenahe Anwendungen ist das immer noch die beste Lösung. Wobei ich die anderen Sprachen nicht gut genug kenne, um ihnen abzusprechen, dass sie dafür nicht oder nicht sogar besser geeignet wären. Das Problem ist halt, das sich erstmal eine durchsetzen muss. Was mich persönlich an C++ nervt, ist dass inzwischen krampfhaft versucht wird alle möglichen und uinmöglichen Features in die Sprache zu packen. Das führt dazu, das modernes C++ unglaublich komplex geworden ist. Nur wirkliche Experten können von sich behaupten, sich damit wirklich auszukennen.
Bist du hier eigentlich auf deinem persönlichen anti-c-C++-Feldzug? Musst du irgendwelche Traumata oder eigene Unfähigkeit, C und C++ zu lernen, aufarbeiten? Dein toller Edit am "STM32 für Einsteiger" Artikel ist übrigens ziemlich vermurkst - die Satzzeichen sind an der falschen Stelle, und es ist nicht vernünftig erläutert - also flaches Trollen.
vielleicht liegt es einfach daran das jemand eine Sprache mag und eine andere nicht? Nichts anderes hat er geschrieben. Vielleicht ist Dr Sommer ja auf einem Pro C Feldzug? Da er ständig dabei ist wenn es gegen C geht um es zu verteidigen? Also betreibt er ganz offensichtlich fachliches Trollen...wenn nicht, bleib doch einfach der Diskussion fern anstatt zu stören!
Mariella M. schrieb: > vielleicht liegt es einfach daran das jemand eine Sprache mag und eine > andere nicht? Und das muss man in einer Reihe neuer Threads proklamieren? Mariella M. schrieb: > wenn nicht, bleib doch einfach der Diskussion fern anstatt zu stören! Eine fachliche Diskussion ist es also nur wenn man gegen C ist?
Gegeg J. schrieb: > Ich denke diese Sprache daher tatsächlich ernstzunehmende Konkurrenz für > C++ werden könnte auch auf lange Sicht im Embedded >bereich und freue > mich darüber, da ich, wie gesagt, den Hype um C bzw C++ nicht verstehen > kann Swift unterstützt manuelle Speicherverwaltung nicht wie C und C++, was man für Embedded braucht. Swifts Metaprogrammierung ist zu dynamisch und Laufzeit-basiert für Embedded. moep schrieb: > Was mich persönlich an C++ nervt, ist dass inzwischen krampfhaft > versucht wird alle möglichen und uinmöglichen Features in die Sprache zu > packen. Die musst du ja nicht nutzen. C++ ist genau das, was herauskommt, wenn man Abstraktion, genaue Kontrolle und Effizienz kombinieren möchte. Bis jetzt gibt es keine Sprache, die das genau so kann; wenn man diese Features haben möchte, braucht man C++. In Zukunft kommt vielleicht (hoffentlich) Rust als Alternative. Andere Sprachen wie Pascal können zwar auch nett sein, aber genau das können sie so eben nicht. Könnten sie es, wären sie nicht so schön freundlich wie sie sind. Habe z.B. letztens mit Kotlin gearbeitet und war traurig dass es keine variadischen templates und Tupel wie C++ kennt, womit man schon ein paar nette Sachen machen kann.
Ist das ein neuer Fliegenfänger-Thread für die "C ist Scheiße" Trolle :-) @"Gegeg", sobald Apple sein Betriebssystem komplett in Swift geschrieben hat nehme ich die Sprache ernst :-)
Udo S. schrieb: > sobald Apple sein Betriebssystem komplett in Swift geschrieben > hat nehme ich die Sprache ernst :-) Du hast nicht verstanden was Swift ist und wozu sie dient?! Es geht nicht darum das man in C ein Betriebssystem programmieren kann und mit Swift nicht..daher bist Du hier gerade völlig falsch Es geht nicht darum das man in C alles machen kann..das kann man in Assembler auch..dennoch ist kaum jemand so behämmert und macht es. Und Swift gibt es bereits in Ansätzen für embedded und hoffe es verbreitet sich weiter oder eben Pascal;-) Die die so heiß auf C sind können ja dabei bleiben und brauchen sich auch hier nicht beteiligen, andere aber schauen vielleicht mal über den Tellerant und sind von C auch eher abgeschreckt, für die ist dieser Faden..für die C Fans....nicht
:
Bearbeitet durch User
Mariella M. schrieb: > Es geht nicht darum das man in C ein Betriebssystem programmieren kann > und mit Swift nicht..daher Im Embedded-Bereich programmiert man aber oft ohne Betriebssystem, d.h. die Anwendung ist wie ein Betriebssystem implementiert. Und das muss mit der Sprache eben gehen.
Dr. Sommer schrieb: > Und das muss mit > der Sprache eben gehen und?! Geht mit Pascal doch auch, wieso sollte es mit Swift nicht machbar sein?!
Mariella M. schrieb: > wieso sollte es mit Swift nicht machbar > sein?! Dr. Sommer schrieb: > Swift unterstützt manuelle Speicherverwaltung nicht wie C und C++, was > man für Embedded braucht.
Mariella M. schrieb: > Die die so heiß auf C sind können ja dabei bleiben und brauchen sich > auch hier nicht beteiligen, andere aber schauen vielleicht mal über den > Tellerant und sind von C auch eher abgeschreckt, für die ist dieser > Faden..für die C Fans....nicht Kritische Stimmen sind nicht erwünscht. An was erinnert mich sowas blos ... Viel Spass noch :-)
unabhängig davon das es in erster Linie gar nicht um Embedded geht, denn antürlich geht swift hierfür..wäre es chön wenn wir bei den Generellen Vorteieln von Sfwift bleiben und die C Missioniererei entfallen könnte.. Jaaaaa C geht für alles, wir haben es verstanden, und genau deshalb ist C auch Kacke für vieles! Dieser Vorteil ist eben auch der fetteste NAchteil. Und darum geht..daher gehe ich jetzt darauf nicht weiter ein, da Faden sonst wie immer von einem einzelnen kaputt gemacht wird.. Es geht darum das das Thema wegen Haarspaltereien kaputt gemacht wird. Nimm embedded raus..und bleib der der PC programmierung...vielleicht ist es sinnvoller..embedded war nur ein Beispiel da es dafür bereits erste Umsetzungen von Swift gibt Das hier steht auch im Bereich PC Programmierung..nicht ohne Grund..darum geht es vordergründig!
:
Bearbeitet durch User
Dr. Sommer schrieb: > Swift unterstützt manuelle Speicherverwaltung nicht wie C und C++, was > man für Embedded braucht. Swifts Metaprogrammierung ist zu dynamisch und > Laufzeit-basiert für Embedded. Was für eine engstirnige Definition von "Embedded". Embedded heißt heute auch gerne mal Quad-Core ARM-A53 mit FPGA-Unterstützung (Xilinx Ultrascale z.B.).
Mariella M. schrieb: > unabhängig davon das es in erster Linie gar nicht um Embedded geht Doch, ging es wohl: Gegeg J. schrieb: > Ich denke diese Sprache daher tatsächlich ernstzunehmende Konkurrenz für > C++ werden könnte auch auf lange Sicht im Embedded >bereich Auf PC/Server-Programmierung sieht das ganze natürlich anders aus, das bestreitet auch keiner. Da tritt Swift dann aber auch in Konkurrenz zu Java, C#, JS, Kotlin, Rust, Scheme, ruby, Python, usw usf., und dann braucht es schon sehr gute Argumente. Das Posten unter verschiedenen Namen in einem Thread ist hier übrigens verboten: Hilfe:Forum Nutzungsbedingungen Ursel schrieb: > Embedded heißt heute > auch gerne mal Quad-Core ARM-A53 mit FPGA-Unterstützung (Xilinx > Ultrascale z.B.). Da ist die Programmierung aber sehr uncharakteristisch für Embedded. Wenn man das alles unter Embedded fasst, könnte man genauso gut auch Programmierung von Servern auf Cortex-A-Basis darunter verstehen. Und selbst wenn, dann sind so gut wie alle anderen Sprachen auch möglich, und dann muss Swift gegen diese bestehen.
Dr. Sommer schrieb: > Andere Sprachen wie Pascal können zwar auch nett sein, aber > genau das können sie so eben nicht. Für Rust, D und Nim wüsste ich jetzt nicht, was gegenüber C++ fehlt. Gut Nim und D haben einen GarbageCollector, aber der ist optional. Und Nim ist für die Nicht-Profis ähnlich einfach wie Python. Aber wenn es nach den Heise-Trollen geht, haben kleine, neue Sprachen eh keine Chance -- es sei denn Apple, Google oder Facebook steht dahinter. https://www.heise.de/forum/heise-Developer/News-Kommentare/Programmiersprachen-Nim-liegt-als-stabile-Version-1-0-vor/forum-434620/comment/
Dr. Sommer schrieb: > Da ist die Programmierung aber sehr uncharakteristisch für Embedded. Nur wenn man deiner engstirnigen Definition folgt. Bei Embedded geht es um mehr als nur einfache Blinkschaltungen auf einem 8-Bit-AVR. Leistungsfähige ARM-SoC werden für viele ganz typische Embedded-Anwendungen eingesetzt. Dr. Sommer schrieb: > Wenn man das alles unter Embedded fasst, könnte man genauso gut auch > Programmierung von Servern auf Cortex-A-Basis darunter verstehen. Ja, Embedded kann manchmal näher an Serverprogrammierung dran sein als deine Blinkschaltungen auf dem AVR.
Stefan S. schrieb: > Für Rust, D und Nim wüsste ich jetzt nicht, was gegenüber C++ fehlt Kannst du gute Tutorials für D und Nim empfehlen, welche auch erklären, wie die komplizierteren C++-Features dort aussehen? Insbesondere eben Move Semantics, RAII, variadische Templates, Fold Expressions, Closures, manuelle Speicherverwaltung... Die üblichen Anfänger-Tutorials zeigen einem nur die Schokoladenseite und man muss schon suchen ob das jetzt wirklich alles kann...
Ursel schrieb: > Leistungsfähige ARM-SoC werden für viele ganz typische > Embedded-Anwendungen eingesetzt. Dann ist das vielleicht der Embedded-Bereich, aber keine Embedded-Programmierung. Und dann ist die Frage nach Embedded-Programmiersprachen hinfällig. Die Wahl der Programmiersprache richtet sich nach der technischen Umgebung, nicht danach, was man letztlich damit macht. Eine Server-Anwendung schreibe ich nicht in C, weil sie Messdaten verarbeitet, und ein Mikrocontroller-Programm nicht in Cobol, nur weil dieser in einer Bank eingesetzt wird!
Dr. Sommer schrieb: > Dann ist das vielleicht der Embedded-Bereich, aber keine > Embedded-Programmierung. Und wieder bestätigt: engstirnige Definition. Dr. Sommer schrieb: > Und dann ist die Frage nach > Embedded-Programmiersprachen hinfällig. Du hast immer noch nicht bemerkt in welchem Unterforum du dich befindest und was das Thema dieses Threads ist.
Gegeg J. schrieb: > Alles was hier von vielen bei C als Vorteil angepriesen wird, ist bei > Swift rausgeworfen/gemieden worden Warum soll man etwas Nutzen, was keine Vorteile bietet ? Eine Sprache lebt von ihren Libraries und Beispielen (Pattern). Daher Python, Java, C/C++, und nicht irgendwas exotisches in dem niemand programmiert. Ist ja bei den uC nicht anders, Arduino und AVR (und früher PIC, die einfache Entwicklung lebte von Microchips AppNotes) statt irgendwelchen moderneren uC anderer Hersteller.
Ursel schrieb: > Und wieder bestätigt: engstirnige Definition. Ok, fassen wir einfach alles unter Embedded Programmierung, von 4-bit-Controllern bis Server-Prozessoren. Weitstirniger geht gar nicht. Inwiefern ist Swift jetzt besser als die Tausend anderen Sprachen die hier möglich sind? Ursel schrieb: > Du hast immer noch nicht bemerkt in welchem Unterforum du dich befindest > und was das Thema dieses Threads ist. Und du hast den Original-Post nicht gelesen.
Ursel schrieb: > Leistungsfähige ARM-SoC werden für viele ganz typische > Embedded-Anwendungen eingesetzt. Die kann man aber programmieren wie einen PC. Da kann man dann auch gleich sowas wie Python benutzen – und benutzt es, was das "ihr wollt doch nur bei eurem geliebtem C bleiben!"-Argument ad absurdum führt. Wofür dann noch 'ne neue Sprache?
Da hast Du einen wunden Punkt getroffen! Zu D kann ich nicht viel sagen, da ich mich in den letzten Jahren hauptsächlich auf Nim konzentriert habe. Und bei Nim ist es so, dass die Profis, im wesentlichen die Core-Devs und die Leute von Status/Etherium2 schon extrem anspruchsvolle Sachen machen, dass alles aber nicht gut dokumentiert ist. Die Anfängertutorials sind aber schon sehr gut, und ich hoffe, dass jetzt nach dem Erscheinen von 1.0 auch mehr fortgeschrittene Tutorials erscheinen. Die Sprache war eben noch im Fluss, da hat keiner Lust etwas zu schreiben, was dann bald wieder überarbeitet werden muss. Insbesondere war das in den letzten Monaten für die Destruktoren und die New-Runtime mit owned Refs der Fall, womit der GC dann wirklich optional und oft auch unnötig werden soll. Wobei -- AST based Macros, Metaprogramming usw. habe ich nicht so viel benötigt, mir ist es aber schon wichtig das es im Gegensatz etwa zu Go verfügbar ist.
Beitrag #5990781 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > Ich schaue mich gerne um was es neues alternatives gibt und weder C oder > C++ konnten mich überzeugen. > > Offenbar kann diese Sprache wieder richtig "Spaß" machen. > Bsic, Pascal/Delphi, Swift so würde es für mich passend aussehen. > C hat einem ziemlich den Spaß verdorben Wieso erinnert dich Swift mehr an Pascal als an C? https://rosetta.alhur.es/compare/Pascal/Swift/# Swift macht Garbage Collection und ist daher eher vergleichbar mit Go. Allerdings implementiert Swift den GC via Reference Counting: https://docs.swift.org/swift-book/LanguageGuide/AutomaticReferenceCounting.html Pascal und C haben deutlich mehr gemein als Pascal und Swift, mal ganz davon abgesehen, dass die BEGIN/END-Syntax von Pascal weitestgehend ausgestorben ist. Wenn du auf der Suche nach einer modernen Pascal-Alternative bist, also keine VM, einfach zu benutzen und langweiliges Feature-Set, dann guck dir lieber Go an. Die GC-Zeiten von Go sind inzwischen so klein, dass man ihn gar nicht mehr bemerkt.
Stefan S. schrieb: > Die Sprache war eben noch im Fluss, da hat keiner Lust etwas zu > schreiben, was dann bald wieder überarbeitet werden muss. Das ist für einen produktiven Einsatz aber etwas hinderlich. C++ ist stabil, sogar ISO-standardisiert, größtenteils abwärtskompatibel, und hat Compiler Unterstützung von vielen Herstellern für viele Plattformen.
Jörg W. schrieb: > Da kann man dann auch > gleich sowas wie Python benutzen – und benutzt es, was das "ihr wollt > doch nur bei eurem geliebtem C bleiben!"-Argument ad absurdum führt. > Wofür dann noch 'ne neue Sprache? Z.B. weil Swift durch die Verwendung in der Apple-Welt Millionen Anwender hat.
Ursel schrieb: > Z.B. weil Swift durch die Verwendung in der Apple-Welt Millionen > Anwender hat. Python hat durch die Verwendung in der echten Welt noch viel mehr Anwender.
Mariella M. schrieb: > Dr. Sommer schrieb: >> Und das muss mit >> der Sprache eben gehen > > und?! Geht mit Pascal doch auch, wieso sollte es mit Swift nicht machbar > sein?! Weil Pascal exakt genau so low-level ist (und genauso alt) wie C mit ein paar zusätzlich eingestreuten Elementen von C++ wie zum Beispiel mehr Typsicherheit, OOP und ein paar rudimentäre Templatefähigkeiten. Es gibt dort kein Laufzeitsystem, keinen "managed code", man muß den Speicher immer noch selber verwalten, man kann dort mit Pointern genauso zielsicher direkt auf dem blanken Silizium herumstochern wie in C. Es hat eigentlich nur eine andere Syntax und schönere Grammatik, ist aber ansonsten so ziemlich das selbe wie C, nur mit schönerer Farbe, Alufelgen und 4-Punkt-Gurten. Aber immer noch ohne Airbags und ohne Autopilot und anderen Schnickschnak. Deshalb kann man es auch für die exakt selben Sachen verwenden und die exakt selben Schweinereien machen wie mit C wenn man die Lust darauf verspürt (oder die Notwendigkeit). Das ist der Unterschied zu fast allen anderen neueren Alternativsprachen.
Dr. Sommer schrieb: > Python hat durch die Verwendung in der echten Welt noch viel mehr > Anwender. Und? Ich behaupte ja auch nicht, dass Python von Swift abgelöst wird. Wie ihr ja selbst sagt: Es gibt tausende Sprachen da draußen, nicht nur die einzig Wahre. Und dass du das Apple-Ökosystem nicht als "echte Welt" anerkennst ist schon ziemlich amüsant.
Dr. Sommer schrieb: > Das ist für einen produktiven Einsatz aber etwas hinderlich. Ja sicher. Die Leute, die viel AST-Macros geschrieben haben, mussten in den letzten Jahren schon einige Anpassungen machen. Mein eigener Code hat aber kaum Anpassungen bedurft. Mit 1.0 soll es ja nun zunächst stabil sein -- bis dann Nim 2.0 kommt. Aber dass kennt man ja auch von Python und Ruby. Das wirklich Hauptproblem von so kleinen Sprachen wie Nim sind die oft fehlenden Bibliotheken, da muss man einiges selber schreiben, oder eben Bindings zu Bibliotheken anderer Sprachen. Letzteres geht aber auch recht gut in Nim. Aber ich schaue schon manchmal etwas neidisch auf all die guten Bibliotheken von etwa Python und Rust.
Alles was hier von vielen bei C als Vorteil angepriesen wird, ist bei
> Swift rausgeworfen/gemieden worden
Warum soll man etwas Nutzen, was keine Vorteile bietet ?
Wurde bereits gesagt...
Weil die Argumente der C Leute völliger Unsinn sind.
C ist ein verbesserter Assebmler..naturgemäßt geht damit nahezu alles
und man ist feier UND GENAU DAS ist das PRoblem!
Wieso verstehen C Leute das nicht? Puzzelt ihr in eurer Freizeit etwa
gerne?
Wer gerne Puzzelt oder knobelt ist bei C sicher gut aufgehoben;-)
"Warum soll man etwas Nutzen, was keine Vorteile bietet ?"
diese Frage verstehe ich nicht..Swift z.B. bietet ja eine Menge
Vorteile! gegenüber C..dennoch findest Du dein C toll..schön...aber nur
weil ich in Assembler auch unter Windows programmieren könnte..ist
niemand zu behämmert...
So ähnlich ist es mit C bzw C++ unter Windows etc..klar kann man
machen..aber es hat mehr Nach als Vorteile durch die Fehleranfälligkeit
Um zum eigentliche Punkt zu kommen!
Es ging darum das mir mit Swift das Programmieren sogar wieder Spaß
macht, wie ebne mit Pascal /Delphi/Freepascal Lazarus auch heute noch.
Dieser Spaß ist mir bei C NIE aufgekommen..es war immer nur
fummelig..ständiges Nachlesen und suchen warum jetzt wieder was nicht
wie erwartet läuft.
Darum geht es hier...
Also noch mal die Bitte..lassen wir bitte die sinnfreie Embedded
disukksion außen vor..SWIFT ist gerade mal 4 Jahre alt und entwickelt
sich sehr schnell
Ursel schrieb: > Z.B. weil Swift durch die Verwendung in der Apple-Welt Millionen > Anwender hat. Java hat durch die Verwendung in der Android Welt Milliarden Anwender. C(++) hat durch die Verwendung in der Google/Amazon/Linux und!!! Apple Welt auch Milliarden. Insofern ist das jetzt kein Kriterium für eine neue Sprache. Wenn ich eine neue Sprache lernen will dann hat das zumindest einen von zwei Gründen a) Ich habe einfach Lust dazu, dann muss ich aber nicht andere Sprachen schlecht reden b) Die Sprache kann etwas (besser) was die bisherigen Sprachen nicht oder nur schlechter können. Dann muss ich aber objektiv vergleichen ohne polemisch zu werden.
Udo S. schrieb: > Insofern ist das jetzt kein Kriterium für eine neue Sprache. Doch, wenn man nicht unter der Prämisse ran geht, dass diese Sprache alle anderen verdrängen wird. Udo S. schrieb: > Wenn ich eine neue Sprache lernen will Das ist eben der springende Punkt: Es gibt haufenweise Entwickler, die diese Sprache schon können, weil sie sie in der Apple-Welt verwenden. Und eigentlich sollte jeder, der beruflich mit Embedded zu tun hat merken, dass die Grenzen zwischen IT und Embedded immer weiter verschwimmen. Allein schon weil viele Embedded-Entwickler sich privat mit App-Entwicklung auf iPhones beschäftigen.
Und warum habt ihr es dann nötig erst mal auf C zu schimpfen? Alleine im 1. Posting Gegeg J. schrieb: > weder C oder C++ konnten mich überzeugen. Gegeg J. schrieb: > C hat einem ziemlich den Spaß verdorben Gegeg J. schrieb: > Alles was hier von vielen bei C als Vorteil angepriesen wird, ist bei > Swift rausgeworfen/gemieden worden Gegeg J. schrieb: > den Hype um C bzw C++ nicht verstehen kann Sorry das ist ein reines "Hate" Posting. Das will nur Konfrontation erzeugen ohne wirkliche Vorteile von Swift zu nennen. Soll ich dir dafür ein richtig fetten Nachteil sagen: Apple hat den Finger drauf, das ist keinen Deut besser als C# wo Microsoft bestimmt was Sache ist.
> > Soll ich dir dafür ein richtig fetten Nachteil sagen: > Apple hat den Finger drauf, das ist keinen Deut besser als C# wo > Microsoft bestimmt was Sache ist. tja..und genau da bin ich völlig anderer Meinung..auch wenn ich kein Iphone besitze und auch kein andere Apple Gerät..sagt der Aktienkurs was völlig anderes. Apple macht durchaus aus Sachen mal richtig gut..und rein vom Feeling her fühlt sich Swift sehr gut an! Die Quellen von Swift sind ebenfalls offengelegt worden. Gerade WEIL Apple seine Finger drauf hat, könnte das erfolgreich werden, was bei Google oder MS nicht geklappt hat. Spätestens wenn swift wirklich, also so richtig für Windows oder UND Linux Verfügbar ist, denke ich geht es sehr steil bergauf
Udo S. schrieb: > Und warum habt ihr es dann nötig erst mal auf C zu schimpfen? Ich habe das nirgends getan. C hat seine Daseinsberechtigung, aber recht wenig Überschneidung mit dem Anwendungsbereich von Swift. Das sind keine direkten Gegner. Udo S. schrieb: > Soll ich dir dafür ein richtig fetten Nachteil sagen: > Apple hat den Finger drauf, das ist keinen Deut besser als C# wo > Microsoft bestimmt was Sache ist. Was aber genau der Grund ist, wieso sie so häufig eingesetzt wird.
Gegeg J. schrieb: > Ich denke diese Sprache daher tatsächlich ernstzunehmende Konkurrenz für > C++ werden könnte auch auf lange Sicht im Embedded >bereich und freue > mich darüber, da ich, wie gesagt, den Hype um C bzw C++ nicht verstehen > kann Hype? C und C++ sind pragmatische Arbeitstiere. Muss man nicht mögen, dass sind aber die Sprachen, in der ein Großteil unserer Software geschrieben ist / wurde. Sowohl C, als auch C++ skalieren dabei von Cortex M0 bis Super-Duper-Cluster ganz gut. In C bin ich sehr nah an dem zu generierenden Maschinen Code und in C++ habe ich zusätzlich, unzählige Abstraktionsmöglichkeiten, mit denen ich auf jeder Ebene arbeiten kann (irgend wann werden aber die Compile-Zeiten lästig). Hier mal ein Rant zu Swift, von jemanden, der mit Swift für Apple gearbeitet hat: https://rant.monkeydom.de/posts/2018/06/10/on-my-misalignment-with-apple_s-love-affair-with-swift Ja, ich könnte mir vorstellen, man Swift dort verwendet, wo jetzt Java und C# zuhause sind (hauptsächlich Desktop), aber es bleiben dann auch die selben kommerziellen Risiken, bei der Verwendung einer Sprache, die genau einer Firma gehört.
Mich wundert es etwas, dass der Swift-Compiler nicht – wie fast alle anderen Compiler – self-hosted, d.h. in seiner eigenen Sprache, sondern in C++ geschrieben ist. Das muss zwar – rein technisch gesehen – kein Nachteil sein, aber: Wenn jemand eine neue Programmiersprache entwickelt, dann tut er das ja meist deswegen, weil er mit den existierenden Sprachen nicht zufrieden ist. Die ersten Versionen des neuen Compilers schreibt er natürlich notgedrungenerweise in einer existierenden Sprache. Aber sobald es die Sprache und der Compiler halbwegs hergeben, portiert er den Compiler auf die neue Sprache und das gleich aus mehreren Gründen: - Er möchte sich von der alten Sprache möglichst schnell verabschieden, denn immerhin war ja die Unzufriedenheit mit ihr mit einer der Gründe, etwas Neues zu entwickeln. - Mit der Möglichkeit, in der neuen Sprache eine komplexe Software wie einen Compiler zu schreiben, weist er nach, dass die Sprache langsam erwachsen wird und bereit auch für andere große Softwareprojekte ist. - Das Self-Hosting ist mit einem großen persönlichen Erfolgserlebnis verbunden und wird deswegen nicht selten als Anlass genommen, die Versionsnummer von 0.x auf 1.0 springen zu lassen. Swift ist nun seit 9 Jahren in Entwicklung, liegt inzwischen in der Version 5.1 vor, ist aber immer noch in C++ geschrieben. Irgendwie vermisse ich da ein wenig den Enthusiasmus der Entwickler.
Dr. Sommer schrieb: > C++ ist genau das, was herauskommt, wenn man Abstraktion, genaue > Kontrolle und Effizienz kombinieren möchte Nun gut, da ist die Frage, wo die Effizienz ist. Jedenfalls nicht bei einer Sprache die 90% der Entwicklungszeit für sich selbst beansprucht und 10% für das Problem, das man mit ihr lösen soll/will. Selbst dem Erfinder von C++ ist das ganze inzwischen zu überladen: http://www.stroustrup.com/P0977-remember-the-vasa.pdf Bei C++ wurde vergessen einfach mal den alten Ballast über Bord zu werfen. Python hat das hinbekommen. Der Umstieg von Python2 auf 3 war vielleicht schmerzhaft, hat sich aber gelohnt.
moep schrieb: > Nun gut, da ist die Frage, wo die Effizienz ist. Jedenfalls nicht bei > einer > Sprache die 90% der Entwicklungszeit für sich selbst beansprucht und 10% > für das Problem, das man mit ihr lösen soll/will. Wilde Behauptungen aufstellen kann jeder. moep schrieb: > Bei C++ wurde vergessen einfach mal den alten Ballast über Bord zu > werfen. Ohne den Ballast keine C-Kompatibilität und damit fällt eins der Hauptargumente weg. Wenn jetzt alle Sprachen ihren Ballast abwerfen, welche ist dann noch abwärtskompatibel? Fortran?
Guck dich sowieso mal C# an. Meine historie auf PC : QBasic TurboPascal/TurboVision (Vor jahren nichts; nur Assembly und C auf embedded) C# Ich was sehr beeindruckt wieviel gedanken gleich sind zwischen Turbo Pascal und C#. Logisch weil der gleichen person da der architect von ist (Anders Heilsberg) (Sorry fuer mein schlechtes Deutsch)
Yalu X. schrieb: > Swift ist nun seit 9 Jahren in Entwicklung, liegt inzwischen in der > Version 5.1 vor, ist aber immer noch in C++ geschrieben. Irgendwie > vermisse ich da ein wenig den Enthusiasmus der Entwickler. Ich glaube du hast nicht ganz verstanden, wie Apple funktioniert. Um Enthusiasmus der Compilerentwickler geht es nicht. Deshalb sind Argumente wie: Yalu X. schrieb: > Mit der Möglichkeit, in der neuen Sprache eine komplexe Software wie > einen Compiler zu schreiben, weist er nach, dass die Sprache langsam > erwachsen wird und bereit auch für andere große Softwareprojekte ist. für Apple irrelevant. Die definieren einfach Swift als eine Standard-Programmiersprache für ihre Geräte und die Entwickler nutzen sie. Und mal ehrlich: Die allermeisten Entwickler interessieren sich einen feuchten Dreck dafür, in welcher Sprache der Compiler entwickelt wurde. Auch wenn manche hier wahrscheinlich jetzt versuchen werden zu erklären, dass man nur ein wahrer Entwickler ist, wenn man jahrelang Compilerbau studiert hat.
Dr. Sommer schrieb: > Wilde Behauptungen aufstellen kann jeder. Es gibt in C++ 3 Arten ein Objekt zu initialisieren. Jede funktioniert ein bisschen anders... Ist das wirklich nötig? Allein die Liste der Bücher mit dem Inhalt "Wie benutze ich C++ richtig" ist so lange, dass einem so langsam dämmern könnte, das mit dieser Sprache was nicht stimmt. Geh mal ein C++ Meet-Up. Dort kannst du dir dann stundenlange Vorträge darüber anhören, was wieder für eine tolle neue Art der Metaprogrammierung entdeckt wurde. Was soll das? Mit C++ kann man sehr gute Software entwickeln. Aber es ist noch viel einfacher Sch*** damit zu bauen. Jetzt kann man natürlich argumentieren, das C++ nur was für echte Profis ist. Und dann sind wir wieder bei dem Punkt, das man einfach zu viel Zeit investieren muss, um darin richtig gut zu werden. Ich würde als Projektleiter bei einem neuen Projekt nie C++ als Sprache einsetzen. Allein schon aus dem Grund, dass es zu viele Leute da draussen gibt, die denken, dass sie sich "richtig gut damit auskennen" und es dann halt doch nicht tun...
moep schrieb: > Jetzt kann man natürlich argumentieren, > das C++ nur was für echte Profis ist. Ja, das ist vermutlich der Grund, wieso manche so drauf stehen. Wenn man der Meinung ist ein guter Entwickler ist derjenige, der möglichst viele ultrakomplexe Konzepte handhaben kann, dann ist C++ genau das richtige. Man könnte stattdessen auch einfach hinterfragen, ob diese Konzepte wirklich so sinnstiftend sind oder nicht eher ein Klotz am Bein sind (bezüglich Wartbarkeit des Codes z.B.).
moep schrieb: > Ist das wirklich nötig? Ja. Wenn man nur die alte Version beibehält, gibt es keinen Fortschritt. Wenn man die alte Version rausnimmt, ist es nicht mehr abwärtskompatibel, was, wie erwähnt, sehr wichtig ist. moep schrieb: > Allein die Liste der Bücher mit dem Inhalt "Wie benutze ich C++ richtig" > ist > so lange, dass einem so langsam dämmern könnte, das mit dieser Sprache > was nicht stimmt. Komplizierte Werkzeuge sind halt kompliziert zu verwenden. Man kann (und sollte, falls möglich) auch einfachere Werkzeuge nutzen, aber die sind dann auch weniger leistungsfähig. moep schrieb: > Was soll das? Man möchte halt nicht auf dem Stand von 1980 stehen bleiben, sondern Weiterentwicklung ermöglichen. moep schrieb: > Aber es ist noch viel > einfacher Sch*** damit zu bauen. Das geht mit allen Sprachen. moep schrieb: > Ich würde als Projektleiter bei einem neuen Projekt nie > C++ als Sprache einsetzen. Also dann doch nur wieder C, auf (kleinen) Embedded Systems? Auch da gibt es sehr viele Fehlermöglichkeiten und der Abwärtskompatibilität geschuldete Skurrilitäten.
Dr. Sommer schrieb: > Wenn jetzt alle Sprachen ihren Ballast abwerfen, > welche ist dann noch abwärtskompatibel? Fortran? Fortran sicher nicht.
Gegeg J. schrieb: > Ich sehe sehr viele Parallelen zu Pascal/Delphi- > Alles was hier von vielen bei C als Vorteil angepriesen wird, ist bei > Swift rausgeworfen/gemieden worden wie bei Pascal auch. > http://www.swiftkurs.de/der-zuweisungsoperator/ Wo siehst Du da Pascal? Ist wohl eher ein neuer C-Dialekt. {} haben bei Pascal völlig andere Bedeutung, Zuweisungsoperator bei Pascal ist := und nicht =, wie bei C. = ist bei Pascal der Vergleichsoperator.
Gegeg J. schrieb:
Wievel Threads dieser Art willst du denn noch anleiern, hast du nix
besseres zu tun?
Ursel schrieb: > Yalu X. schrieb: >> Swift ist nun seit 9 Jahren in Entwicklung, liegt inzwischen in der >> Version 5.1 vor, ist aber immer noch in C++ geschrieben. Irgendwie >> vermisse ich da ein wenig den Enthusiasmus der Entwickler. > > Ich glaube du hast nicht ganz verstanden, wie Apple funktioniert. Offensichtlich anders als Microsoft, Google und Mozilla, zumindest was die Entwicklung neuer Programmiersprachen und Compiler betrifft. Ursel schrieb: > Die definieren einfach Swift als eine Standard-Programmiersprache für > ihre Geräte und die Entwickler nutzen sie. Kann schon sein, dass die das so klar und einfach sehen. Aber wenn du recht hast, ist es dann überhaupt sinnvoll, Swift auf etwas anderem als iPhone oder iPad zu nutzen? Oder sollten wir dem TE einfach sagen: "Vergiss es."?
Man sollte auch nicht vergessen, dass Swift nach C (in OS9) und Objective-C (in OSX) Apples 3. "offizielle" Sprache ist. Nicht, dass man viel Zeit und Geld in Swift investiert und Apple dann mit irgendwas Neuem um die Ecke kommt...
Yalu X. schrieb: > Offensichtlich anders als Microsoft, Google und Mozilla, zumindest was > die Entwicklung neuer Programmiersprachen und Compiler betrifft. Ganz richtig. Yalu X. schrieb: > Kann schon sein, dass die das so klar und einfach sehen. Aber wenn du > recht hast, ist es dann überhaupt sinnvoll, Swift auf etwas anderem als > iPhone oder iPad zu nutzen? Wenn du Swift sowieso beherrscht, weil du es von Apple-Geräten kennst, kann das durchaus sinnvoll sein. Wenn nicht dann wohl eher weniger . Aber es geht wie gesagt gar nicht darum, alle andere Sprachen zu 100% zu ersetzen.
Ursel schrieb: > Das ist eben der springende Punkt: Es gibt haufenweise Entwickler, die > diese Sprache schon können, weil sie sie in der Apple-Welt verwenden. > Und eigentlich sollte jeder, der beruflich mit Embedded zu tun hat > merken, dass die Grenzen zwischen IT und Embedded immer weiter > verschwimmen. Allein schon weil viele Embedded-Entwickler sich privat > mit App-Entwicklung auf iPhones beschäftigen. Soso "viele Embedded-Entwickler". Du hast leider die Quelle deiner Aussage vergessen zu posten, hört sich nämlich an wie ausgedacht. Selbst wenn sich viele Embedded-Entwickler mit App-Entwicklung beschäftigen wollen (was ich arg bezweifle), scheitert es meist daran, dass man dafür zwingend ein Gerät mit Mac OS X benötigt, selbst wenn man Xamarin benutzt. Ursel schrieb: > Und eigentlich sollte jeder, der beruflich mit Embedded zu tun hat > merken, dass die Grenzen zwischen IT und Embedded immer weiter > verschwimmen. Das könnte direkt aus einer Marketingabteilung kommen, weil es keinerlei Aussagekraft hat (vgl. Grenzen zw. Autos und Fahrzeugen verschwimmen). Embedded ist und war schon immer IT. Ja Eingebettete Systeme müssen immer direkt mit dem Internet kommunizieren, aber warum deswegen eine Sprache, die aus einer ganz anderen Domäne kommt (Anwendungsentwicklung) und von einem Konzern der überhaupt nichts mit Embedded zu tun hat, sich nun breit machen sollte, wurde hier immer noch nicht dargelegt. Zumal es zahlreiche Alternativen gibt. Aber das Argument "Apple" scheint für manche alles schlagen zu können. Eine Sprache die C und C++ im Embedded-Bereich verdrängen will, muss genauso performant, universal einsetzbar, low-level fähig sein, "zero cost abstraction" unterstützen und ein besonderes Feature haben, was die Leute zum Umsteigen bewegen kann. Das Potential sehe ich bisher nur in Rust.
Dr. Sommer schrieb: > Also dann doch nur wieder C, auf (kleinen) Embedded Systems? Auch da > gibt es sehr viele Fehlermöglichkeiten und der Abwärtskompatibilität > geschuldete Skurrilitäten. Meiner Meinung nach ja. Zumindest, wenn es um Embedded Projekte ohne OS oder nur mit einem RTOS geht. Bei einem leistungsfähigen Controller mit Linux-Unterstützung gibt es inzwischen genug Alternativen zu C/C++. Ich hab mir mal Rust angesehen und war positiv überrascht davon. Gerade weil die Sprache schon so designt ist, das es einem schwer gemacht wird, Mist zu bauen. Und der Compiler spuckt richtig sinnvolle Fehlermeldungen aus, bei denen einem schnell klar wird, was ihm nicht passt. Aber das ist, wie gesagt, meine persönliche Meinung.
TriHexagon schrieb: > Soso "viele Embedded-Entwickler". Du hast leider die Quelle deiner > Aussage vergessen zu posten, hört sich nämlich an wie ausgedacht. Ich arbeite tagtäglich mit Entwicklern zusammen. TriHexagon schrieb: > Selbst wenn sich viele Embedded-Entwickler mit App-Entwicklung > beschäftigen wollen (was ich arg bezweifle), scheitert es meist daran, > dass man dafür zwingend ein Gerät mit Mac OS X benötigt, selbst wenn man > Xamarin benutzt. Das ist das geringste Problem. TriHexagon schrieb: > Embedded ist und war schon immer IT. Ich denke wer die Aussage nicht absichtlich falsch auslegen will versteht was ich meine. Ich meinte die Embedded-Entwicklung, die eher von "Ingenieurslastigen" Unternehmen getrieben wird und den großen IT-Unternehmen. TriHexagon schrieb: > aber warum deswegen eine > Sprache, die aus einer ganz anderen Domäne kommt (Anwendungsentwicklung) > und von einem Konzern der überhaupt nichts mit Embedded zu tun hat, sich > nun breit machen sollte, wurde hier immer noch nicht dargelegt. Weil immer mehr Entwickler von der einen Seite Anwendungen für die andere entwickeln. TriHexagon schrieb: > Aber das Argument "Apple" scheint für > manche alles schlagen zu können. Auch das spielt selbstverständlich eine Rolle. In der Geschichte der Technik gibt es unzählige Beispiele dafür, dass sich nicht unbedingt das technisch beste System durchgesetzt hat. TriHexagon schrieb: > Eine Sprache die C und C++ im Embedded-Bereich verdrängen will Von verdrängen redet hier keiner, außer diejenigen, die C/C++ verteidigen (nicht einmal der OP, der ja offensichtlich ein Troll ist). Das ist ein typisches Strohmann-Argument.
Ursel schrieb: > Und mal ehrlich: Die allermeisten Entwickler interessieren sich > einen feuchten Dreck dafür, in welcher Sprache der Compiler entwickelt > wurde. Ganz ehrlich: das ist Unfug. Ein Compiler, der sich selbst erstellt, hat eine Fehlerquelle. Ein Compiler, der von einem anderen Compiler erstellt wird, hat zwei Fehlerquellen. Jeder, der auch nur ein ganz klein wenig darüber nachdenkt, wird sich für die Variante "nur eine Fehlerquelle" entscheiden. Wenn Swift nicht dazu geeignet ist, einen Swift-Compiler zu erstellen, hat Apple selber wohl noch Angst vor dem eigenen Compiler. Und das ist ein guter Grund, es Apple gleich zu tun, und kein Swift zu verwenden.
Gegeg J. schrieb: > SWIFT gibt es mittlerweile auch für Windows. Super Argument. MUMPS gibt es auch für Windows, läuft sogar auf PDP11, VAX und R6000. > Der Pascal/Delphi Vergleich bezieht sich auf aktuelle Versionen nicht au > die Urzeiten aus den 78-90er Jahre! Was hast du gegen Delphi? Alles was ich davon kenne wurde relativ schnell erstellt und läuft sehr gut. Eine der besten Entwicklungsumgebungen. Die Progger die ich kenne sind da nur Weg (zu C C++) weil es da ein gigantische Menge fertige, getestete und portierbare Module gibt. > Apple selbst stellt seine eigenen Anwendungen auf Swift um, Das ist natürlich ein Argument für eine Sprache. Dieser -meins-meins-meins- Konzern ist sicher die erste Anlaufstelle für Compiler. Vermutlich mit Alulochblenden und 60 Jahre Küchenschleiflack als Unit(/Ironie) Wenn die Post Elektrolaster baut dann hol ich mir auch einen. Weil den Paketboten kenne ich ja.
"Was hast du gegen Delphi? " nichts habe ich gegen das Delphi von damals. Nur die C Verteidiger haben die dumme Angewohnheit das C bzw C++ von heute mit dem Pascal/Delphi von damals zu vergleichen, vergessen aber das auch Delphi und erst recht FreePascal erhebliche Entwicklungen mitgemacht hat. Das Apple jetzt selber darauf setzt, ist deshalb erwähnenswert, da es dann offensichtlich langsam für den praktischen Einsatz taugt und keine so gravierenden Änderungen mehr kommen werden, die alles vorherige über den Haufen werfen
:
Bearbeitet durch User
S. Z. schrieb: > Ein Compiler, der sich selbst erstellt, hat eine Fehlerquelle. > > Ein Compiler, der von einem anderen Compiler erstellt wird, hat zwei > Fehlerquellen. Wenn das so wäre, dürfte jedes Programm nur genau einen Bug haben. Denn es gibt ja nur eine Fehlerquelle. Nein, das ist nun wirklich etwas zu einfach gedacht. Viel entscheidender als die Sprache, in der der Compiler entwickelt wurde, ist die Frage, wie sorgfältig bei der Entwicklung gearbeitet wurde. Und da ist weder die eine noch die andere Variante systematisch im Vorteil. S. Z. schrieb: > Wenn Swift nicht dazu geeignet ist, einen Swift-Compiler zu erstellen, > hat Apple selber wohl noch Angst vor dem eigenen Compiler. Wer sagt denn, dass Swift nicht dafür geeignet wäre? Das leitest du doch nur aus deinem persönlichen Anspruch ab. Aber glaubst du ernsthaft, Apple richtet sich nach dir? S. Z. schrieb: > Und das ist > ein guter Grund, es Apple gleich zu tun, und kein Swift zu verwenden. Nur verwendet Apple sehr wohl selbst Swift.
Yalu X. schrieb: > Mich wundert es etwas, dass der Swift-Compiler nicht – wie fast alle > anderen Compiler – self-hosted, d.h. in seiner eigenen Sprache, sondern > in C++ geschrieben ist. Die meisten Kompiler heute sind sowieso clang frontends. Die aktuelle Version von clang und gcc können sich nichtmehr selbst bootstrappen. Dafür muss man noch ein zwei ältere Version vorrätig halten, aber nichts zu altes oder zu neues...
Bei C# stört mich das man es nicht einfach auf einer x beliebigen Windows Version laufen lassen kann:-( Wobei das bei swift natürlich auch nie anders sein wird, selbst wenn es weiter in die Richtung geht. Das ist halt das was ich an Delphi/Freepascal/Lazraus so herausragend finde..es läuft einfach alles. Und selbst wenn man Sourcen teilt, geht es immer nur um Delphi oder Freepascal, es gibt nicht wie in C 100 verschiedene Compiler und Versionen , wo nichts mal eben schnell runtergeladen und kompiliert ist..außer ist wurde gerade der Hauscompiler z.B. gcc genutzt
Gegeg J. schrieb: > Und selbst wenn man Sourcen teilt, geht es immer nur um Delphi oder > Freepascal, Ja, weniger Auswahl und Möglichkeiten ist nämlich ein Vorteil! Gegeg J. schrieb: > wo nichts mal eben schnell runtergeladen und kompiliert > ist..außer ist wurde gerade der Hauscompiler z.B. gcc genutzt Standardkonformer C-Code läuft mit jedem Compiler auf praktisch jeder Plattform, außer solchen, die nur Assembler können. Da kommt Pascal nicht ran. Gegeg J. schrieb: > außer ist wurde gerade der Hauscompiler z.B. gcc genutzt Dann ist Delphi hat das Hausdelphi...
"Ja, weniger Auswahl und Möglichkeiten ist nämlich ein Vorteil!" jep, genau das ist es. Bei mir ist es Lazarus..aber es gitb eben nur die zwei, eine Anpassung und mittlerweile meist fix gemacht und der hochgelobte C Standard ist nicht mehr so Standard wenn man vor dem PRoblem steht, dann müssen dort auch Anpassungen gemacht werden..
Gegeg J. schrieb: > "Ja, weniger Auswahl und Möglichkeiten ist nämlich ein Vorteil!" > jep, genau das ist es. Dann fändest du es bestimmt auch super, wenn's nur ein Auto (Trabant), eine Bank und ein Betriebssystem gäbe? Endlich keine Auswahl mehr! Gegeg J. schrieb: > und der hochgelobte C Standard ist > nicht mehr so Standard wenn man vor dem PRoblem steht, dann müssen dort > auch Anpassungen gemacht werden.. Häwas? Der ist ISO-Standard und alle richtigen C-Compiler sind konform.
Dr. Sommer schrieb: > Dann fändest du es bestimmt auch super, wenn's nur ein Auto (Trabant), > eine Bank und ein Betriebssystem gäbe? Endlich keine Auswahl mehr! Ich finde es äußerst vorteilhaft daß es nur eine Sorte Superbenzin gibt und keine 42 inkompatiblen, nur eine Sorte Wechselstrom an der Steckdose auf dem ganzen Kontinent, nur eine Sorte Euro-Bargeld das bei jeder Bank funktioniert und nur eine Sorte Lazarus das jedes Lazarus-Programm kompiliert.
Dr. Sommer schrieb: > Dann fändest du es bestimmt auch super, wenn's nur ein Auto (Trabant), > eine Bank und ein Betriebssystem gäbe? Endlich keine Auswahl mehr! Merke: "Nicht alles, was hinkt, ist ein Vergleich..."
Gegeg J. schrieb: > "Ja, weniger Auswahl und Möglichkeiten ist nämlich ein Vorteil!" > jep, genau das ist es. Hat was von Orwellsche Logik: "Freedom Is Slavery". Gegeg J. schrieb: > Bei mir ist es Lazarus..aber es gitb eben nur die zwei, eine Anpassung > und mittlerweile meist fix gemacht und der hochgelobte C Standard ist > nicht mehr so Standard wenn man vor dem PRoblem steht, dann müssen dort > auch Anpassungen gemacht werden.. Jetzt rate mal für was so ein Standard gut ist.
Gegeg J. schrieb: > "Ja, weniger Auswahl und Möglichkeiten ist nämlich ein Vorteil!" > jep, genau das ist es. > Bei mir ist es Lazarus..aber es gitb eben nur die zwei, eine Anpassung > und mittlerweile meist fix gemacht Dann ist ja Swift genau das Richtige für dich, da gibt es m.W. sogar nur einen einzigen Compiler, der deswegen auch an nichts angepasst werden muss. Und du kannst damit sogar Apps für IPhone und iPad schreiben :)
Wenn die Existenz nur eines einzigen Compilers für dich ein wichtiges Kriterium für eine Programmiersprache ist, gibt es noch eine ganze Reihe weiterer (vor allem jüngerer) Sprachen, die dir gefallen müssten. Rust gehört bspw. auch dazu. Aber Vorsicht: Mit zunehmender Verbreitung einer Sprache wächst i.Allg. auch die Anzahl verfügbarer Compiler. Pascal und seine Nachfolger scheinen von vielen nicht besonders gemocht zu werden, deswegen besteht dort kein Gefahr einer Compilerschwemme mehr. Das war aber nicht immer so: In den 80er Jahren, als die Popularität von Pascal noch auf ihrem Höchststand war, war es nach Basic wohl die Sprache mit den zweitmeisten (untereinander inkompatiblen) Dialekten.
Solange die Referenzimplementation unter einer freien Lizenz steht gibt es immer exakt genau so viele Implementierungen wie benötigt werden: Nämlich immer mindestens eine (solange die Idee an sich noch nicht tot ist) und bei Bedarf(!) beliebig viele mehr.
so sieht es aus. Freepascal und Lazarus arbeiten hervorragend zusammen..Alle Versuche von anderen eine eigene Oberfläche zu entwickeln verlaufen im Sand, da Lazarus völlig i.O. ist. Die Pascalunterstützung im GCC wurde eingestellt..da kein bedarf..Freepascal ist meilenweit voraus Nur bei C /C++ gibt es 100.000 die ihr eigenes Süppchen kochen...alle nach einem Standard...oft basierend auf gcc oder eben auch nicht, zig Oberflächen, da das non Plus Ultra nicht dabei ist..entweder zu fett oder unvollständig, kompliziert oder unübersichltich..und je mehr es gibt, desto geringer ist die Wahrscheinlichkeit das sich noch eins davon als der Standard durchsetzten wird.. Nur die C Fraktion verkauft da als Vorteil...
Gegeg J. schrieb: > und je mehr es gibt, desto geringer ist die Wahrscheinlichkeit das sich > noch eins davon als der Standard durchsetzten wird Warum sollte es auch? Weil dir Lazarus gefällt, muss es allen gefallen? Das klingt ein bisschen nach: "Wer meinen Gott nicht mag, soll gar keinen haben."
Gegeg J. schrieb: > Du hast den Kern der Aussage nicht verstanden... Kann sein. Ich kann deinen behaupteten Vorteil nicht als solchen erkennen. Und nein, das hat mit der Programmiersprache rein gar nichts zu tun.
Ja. Garbage collector & embedded... davon habe ich schon lange getraeumt...
Yalu X. schrieb: > Pascal und seine Nachfolger scheinen von vielen nicht besonders gemocht > zu werden, deswegen besteht dort kein Gefahr einer Compilerschwemme > mehr. Ist das "viele mögen etwas" neuerdings ein Zeichen von Qualität? Viele mögen die Bild. Viele mögen Microsoft Produkte. Viele mögen einen SUV. Viele mögen Kippen und Alk. Und wie steht es um die vielen BASIC-Dialekte? Würden die von vielen gar nicht mehr gemocht, gäbe es sie doch mittlerweile praktisch kaum noch mehr, was aber nicht wirklich der Fall ist. Irgend etwas emotional anziehendes muss doch PASCAL/Lazarus besitzen, dass C/C++ einfach nicht hat. Mutmaßung: Insbesondere C++ scheint für viele sich nicht primär zu verbessern, sondern hauptsächlich immer komplexer zu werden. Für C++ Profis (d.h. Leute die damit täglich ihr Geld verdienen (müssen)) mag das nicht so sein bzw. sehen wahrscheinlich nur Verbesserungen. In der eigenen Echokammer sieht man die Dinge naturgemäß anders, meist rosiger. Von außen betrachtet suchen viele die nicht full time programmieren (müssen) lieber nach einfacheren Lösungen. Viele haben einfach nicht die Zeit und vielleicht auch nicht die geeigneten Voraussetzungen (so wie nicht jeder der Abi hat automatisch ein Mathe-Crack ist, selbst wenn er Mathe Leistungskurs hatte) um in C++ ihre Programmierideen ohne all zu viel Stress umzusetzen. > Das war aber nicht immer so: In den 80er Jahren, als die > Popularität von Pascal noch auf ihrem Höchststand war, war es nach Basic > wohl die Sprache mit den zweitmeisten (untereinander inkompatiblen) > Dialekten. Das war damals wohl Borland's Turbo Pascal für DOS geschuldet. Leider hat TP den Übergang zu Windows nicht erfolgreich gemeistert und wurde von C/C++ überrannt. Vielleicht einer der Gründe warum Lazarus heute so beliebt ist, weil es damals fehlte und heute gut genug für viele und vieles ist (natürlich nicht für alles, aber das gilt auch für C++, sonst gäbe es schließlich kein Python u.a.).
C# schrieb: > Ist das "viele mögen etwas" neuerdings ein Zeichen von Qualität? Getroffene Hunde bellen? Oder was soll der Rant sonst? Yalu hatte nur festgestellt, dass es bei Pascal wohl keine Gefahr gibt, dass da nunmehr noch zu viele Compiler aus dem Nichts erstehen, und dass das durchaus mal anders war.
Jörg W. schrieb: > C# schrieb: >> Ist das "viele mögen etwas" neuerdings ein Zeichen von Qualität? > > Getroffene Hunde bellen? Oder was soll der Rant sonst? Warum so empfindlich, das war weder ein "Rant" noch habe ich "gebellt". Ich schrub lediglich meine Meinung hier nieder. > Yalu hatte nur festgestellt, dass es bei Pascal wohl keine Gefahr gibt, > dass da nunmehr noch zu viele Compiler aus dem Nichts erstehen, und dass > das durchaus mal anders war. So hat er das aber nicht festgestellt. Er schrieb "Pascal und seine Nachfolger scheinen von vielen nicht besonders gemocht zu werden". Mal abgesehen davon, dass sich alles was in den letzten Jahren an Programmiersprachen gehypt wurde sich erstmal so lange wie PASCAL/Lazarus halten muss, ist die Aussage an sich ja schon fragwürdig. Denn beispielsweise C# kann man durchaus unter die Nachfolger von PASCAL einordnen, denn Anders Hejlsberg entwickelte erst für BORLAND (PASCAL) dann DELPHI und schließlich C#/.NET für Microsoft (grob gesagt) und von letzterem zu behaupten dieser Nachfolger sei von vielen "nicht gemocht" ist schon ein starkes Stück. Genau das Gegenteil ist der Fall.
Yalu X. schrieb: > Pascal und seine Nachfolger scheinen von vielen nicht > besonders gemocht zu werden, deswegen besteht dort > kein Gefahr einer Compilerschwemme mehr. Echt jetzt?! Das bedeutet dann, dass Nobelpreise und Olympiamedaillen von vielen nicht besonders gemocht werden, weswegen auch relativ wenig Leute so etwas haben, nicht wahr?
C# schrieb: > Denn beispielsweise C# kann man durchaus unter die Nachfolger von PASCAL > einordnen Das ist natürlich eine ziemlich gewagte Schlussfolgerung, um nicht zu sagen, eine schlichte Vereinnahmung deinerseits, damit alles irgendwie in die Pascal-Brille passt. Schließlich ist es doch gerade die ach so schröckliche C-Syntax, die vielen Pascal-Liebhabern auf den Keks geht, und genau die hat C# natürlich erstmal von seinem Namensvetter geerbt (genauso wie Java zuvor). Es ist schon lustig, was für eine Religion aus so einem Werkzeug wie einer Programmiersprache manche Leute so machen. Mir ist die benutzte Sprache mittelmäßig egal, solange sie mich brauchbar zu meinem Ziel führt. Das tut derzeit in meinem Aufgabenfeld allerdings in erster Linie C (oder "einfaches" C++), für alle komplexeren Dinge gehe ich eher in Richtung Python, Perl oder ggf. auch Lua. Deshalb bin ich aber weder "Fanboy" oder sonstwas, es sind eben Werkzeuge.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > C# schrieb: > Denn beispielsweise C# kann man durchaus unter die Nachfolger von PASCAL > einordnen > > Das ist natürlich eine ziemlich gewagte Schlussfolgerung, Auch nicht gewagte als die von Yalu und an der hat dich schließlich nichts gestört. Komisch. um nicht zu > sagen, eine schlichte Vereinnahmung deinerseits, damit alles irgendwie > in die Pascal-Brille passt. Die ich gar nicht auf habe oder habe ich hier massiv für Pascal getrommelt? Mit gerade mal ein, zwei Postings? Wohl kaum. > Schließlich ist es doch gerade die ach so > schröckliche C-Syntax, die vielen Pascal-Liebhabern auf den Keks geht, Mir aber nicht, darum mag ich auch C# und > und genau die hat C# natürlich erstmal von seinem Namensvetter geerbt > (genauso wie Java zuvor). ja, du hast recht, C# ist gefühlt nah an C und daran ist nix schlechtes. Warum dennoch viele die Lazarus lieben es nicht durch C# ersetzen mögen liegt wohl weniger (bis gar nicht) an der Syntax, sondern am dot-NET. > > Es ist schon lustig, was für eine Religion aus so einem Werkzeug wie > einer Programmiersprache manche Leute so machen Hab ich noch nie gemacht. >. Mir ist die benutzte > Sprache mittelmäßig egal, solange sie mich brauchbar zu meinem Ziel > führt. Das tut derzeit in meinem Aufgabenfeld allerdings in erster Linie > C (oder "einfaches" C++), für alle komplexeren Dinge gehe ich eher in > Richtung Python, Perl oder ggf. auch Lua. Deshalb bin ich aber weder > "Fanboy" oder sonstwas, es sind eben Werkzeuge. Die Frage ist immer, ob man seine Werkzeuge frei aussuchen kann oder nicht. Wer wählt schon freiwillig ein Werkzeug mit maximaler Komplexität, wenn er sein Ziel auch mit einfacheren Mitteln erreichen kann und dabei auch noch Freude empfindet.
C# schrieb: > Die Frage ist immer, ob man seine Werkzeuge frei aussuchen kann oder > nicht. Abgesehen von Hobbyprojekten kann man das wohl in der Regel nicht, weil es noch andere Randbedingungen gibt (zu unterstützende Plattform, bereits vorhandener Code, sowohl intern als auch extern, Kundenanforderungen), die da mitspielen.
Hallo, C# schrieb: > Wer wählt schon freiwillig ein Werkzeug mit maximaler > Komplexität, wenn er sein Ziel auch mit einfacheren > Mitteln erreichen kann und dabei auch noch Freude empfindet. Man ist andererseits aber auch nicht gezwungen alle nur erdenklichen Eigenschaften eines Werkzeuges vollständig zu nutzen. rhf
Was ist denn nun mit dem Thread-Thema (vermutete Vergleichbarkeit Swift/Pascal)? Hier fliegen schon wieder die Fetzen hauptsächlich über Pascal, obwohl die Eigenschaften dieser altehrwürdigen Sprache und die Eigenschaften ihrer wenigen heute noch aktiv verwendeten Implementierungen doch nun wohl alle bis ins letzte Detail bekannt sind und allesamt schon tausend Mal bis zum Erbrechen durchgekaut wurden! Da ergibt sich nichts neues! Aber was ist jetzt mit Swift, jemand der mit so einem Threadtitel geködert wird (vorwiegend Leute aus der Pascal-Ecke) erwartet bei so einer Themenstellung Antworten auf folgende Fragen: * Wird es direkt zu Maschinencode kompiliert (kein Jit)? * Wie wird der Speicher gemanaged (Garbage-Collector oder nicht?) * Habe ich Datentypen deren Speicherlayout exakt vorhersagbar ist und kann ich jedes beliebige physikalische Speicherlayout (Register, etc) auf dem blanken Silizium direkt mit Code abbilden und in völlig kontrollierter Weise direkt ansprechen? Komm ich ohne Verrenkungen und ohne jeglichen Overhead in eleganter Weise bis herunter aufs blanke Silizium wenn ich das will? * Lässt es sich somit wie Pascal und C(++) und Rust (und andere) in die Kategorie "Systemprogrammiersprache" einordnen? Über diese Fragen in Bezug auf Swift erwarte ich eine Auseinandersetzung wenn im Threadtitel großspurig mit Pascal geködert oder derartiges nahegelegt wird! Nicht über das ganze andere Geschwafel das hier zum 1000-und-ersten Mal wieder durchgekaut wird obwohl im Keller schon die Bartwickelmaschine auf Hochtouren rattert! Also wo ist die Diskussion über die Vorzüge und Nachteile von Swift, welche Sachen damit besser gehen, welche Sachen damit schlechter/nicht gehen? Denkt mal drüber nach!
:
Bearbeitet durch User
es fühlen sich bei solchen Themen irgendwie immer die C Fanboys angesprochen..wo wir wieder bei dem Thema Religion sind. Es ist faktisch keine brauchbare Diskussion in diesem Forum möglich, da immer irgendwelche C Freaks aus ihrem Kellerzimmer kommen und meinen ihre Sprache verteidigen zu müssen..nur hat sie niemand gefragt..sie drängen sich einfach auf. Und wie eigentlich immer ist diese Thema bereits jetzt verheizt dadurch Wie war das mit den 1000 Scheißhausfliegen die sich nicht irren...
Beitrag #5996104 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > es fühlen sich bei solchen Themen irgendwie immer die C Fanboys > angesprochen..wo wir wieder bei dem Thema Religion sind. > Es ist faktisch keine brauchbare Diskussion in diesem Forum möglich, da > immer irgendwelche C Freaks aus ihrem Kellerzimmer kommen und meinen > ihre Sprache verteidigen zu müssen..nur hat sie niemand gefragt..sie > drängen sich einfach auf. > Und wie eigentlich immer ist diese Thema bereits jetzt verheizt dadurch Du hast in deinem Post, mit dem du diesen Thread gestartet hast, 5 Mal C und/oder C++ angesprochen. Da kannst du dich kaum beschweren, wenn andere das auch machen, nur weil dir die Argumente nicht gefallen.
Gegeg J. schrieb: > nur das es um C gar nicht geht.. Du hast direkt mit C verglichen. Worum geht es sonst? Aber an einer sachlichen Diskussion bist du offensichtlich nicht interessiert: Gegeg J. schrieb: > Wie war das mit den 1000 Scheißhausfliegen die sich nicht irren... Ja ich sehe das als Beleidigung. Es gibt keinen Grund so etwas in diesem Zusammenhang zu schreiben, ohne das Ziel jemanden zu beleidigen.
Beitrag #5996129 wurde von einem Moderator gelöscht.
eigentlich schieb ich nur das Swift genau wie Pascal wieder richtig Spaß macht und das C mir keinen Spaß gemacht hat... Analysiere das und denke noch mal drüber nach..worum geht es dabei im Kern? Wie gesagt..der Faden hier ist verbrannt..ich bin aus dem Thema hier raus. Sinnfreie Randdiskussionen sind sinnlose Zeitverschwendung
Beitrag #5996139 wurde von einem Moderator gelöscht.
Beitrag #5996144 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > eigentlich schieb ich nur … etwas von "Hype", was nun nicht gerade sachlich zu nennen ist.
Beitrag #5996165 wurde von einem Moderator gelöscht.
Beitrag #5996169 wurde von einem Moderator gelöscht.
Beitrag #5996401 wurde von einem Moderator gelöscht.
Gegeg J. schrieb: > es fühlen sich bei solchen Themen irgendwie immer die C Fanboys > angesprochen..wo wir wieder bei dem Thema Religion sind. > Es ist faktisch keine brauchbare Diskussion in diesem Forum möglich, da > immer irgendwelche C Freaks aus ihrem Kellerzimmer kommen und meinen > ihre Sprache verteidigen zu müssen.. Dann geht doch in ein Appleforum mit deinem Swiftscheiss, dort wirst du bejubelt werden. Mikrocontrollerentwicklung ist nun mal 99% C/C++, irgendwelche Spielzeugsprachen von einem Hersteller der überteuerte Scherzartikel produziert interessiert hier keinen. Dass man dir das noch erklären muss sagt viel über deinen Geisteszustand aus. > Wie war das mit den 1000 Scheißhausfliegen die sich nicht irren... Das Argument der eingeschnappten Argumentlose schlechthin musste ja wieder kommen wenn einem sonst nix mehr einfällt. Jetzt ab mit dir zu appletalk, macuser, etc da könnt ihr euch an Swift gegenseitig aufgeilen, scheinst sowas zu brauchen.
Franko S. schrieb: > Dann geht doch in ein Appleforum mit deinem Swiftscheiss Aber, aber, ich möchte doch um etwas elaboriertere Wortwahl bitten. Nein, das Thema darf durchaus auch hier (im Subforum "PC-Programmierung") diskutiert werden. Nur sollte nicht jeder (egal, welchen Standpunkt er vertritt) gleich beim ersten Gegenargument in Paranoia verfallen.
Beitrag #5997444 wurde von einem Moderator gelöscht.
Beitrag #5997462 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.