Diskussion:BASIC
Füge neue Diskussionsthemen unten an:
Klicke auf , um ein neues Diskussionsthema zu beginnen.| Zum Archiv |
| Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 30 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. |
Objektorientierte Sprachelemente
[Quelltext bearbeiten]Mit Einführung von objektorientierten Sprachelementen wurde ein weiterer Versuch unternommen, Visual Basic mit anderen objektorientierten Programmiersprachen wie C++ und Java gleichziehen zu lassen.
Ich glaube schon, das man das so stehenlassen kann, da auch vb.net zum Anfang bei den objektorientierten Sprachelementen schwächer als C++, Java und C# war... --2.205.252.151 20:43, 31. Dez. 2011 (CET)
Jahreszahl
[Quelltext bearbeiten]Fehler? In der Einleitung steht 1964, unter Geschichte steht 1963 in nahezu dem selben Satz.. -- 93.128.216.59 15:06, 8. Mai 2009 (CEST)
en:Talk:BASIC programming language Frage: Gibt es eine GNU-Fassung eines BASIC-Compilers, der direkt in Maschinensprache uebersetzt?
- Ich habe folgendes gefunden:
-- Paul Ebermann 01:10, 10. Sep 2002 (UTC)
Warum ging die Bedeutung von Basic zurück
[Quelltext bearbeiten]Ich bin nicht der Meinung, das das fehlen eines BASIC-Compilers/Interpreters unter Windoof, als Ursache führte, das BASIC in vergessenheit geraten ist. Erstens hatte BASIC immer seine Nische, zweitens gabe es unter ATARI-ST und AMIGA schon genügend Pascal, Modula-2 und andere Compiler, und last but not least kam sehr schnell, mit Einführung von Windoof eine GFA-Version für MS-Windows heraus, die leider, leider sehr teuer war, im gegensatz zu der Atari-Version. --Arbol01 18:28, 6. Okt 2004 (CEST)
- Ich bin auch nicht der Ansicht, dass BASIC irgendwann vergessen wurde. Interessant ist vielleicht die Tatsache, dass die ersten Original IBM-PCs (also die von IBM mit 8088 Prozessor) mit einem ROM-BASIC ausgestattet waren, das bei den Kompatiblen aus Fernost und bei Compaq-PCs aus lizenzrechtlichen Gründen dann fehlte. --Hubi 11:06, 7. Okt 2004 (CEST)
- Das ROM-Basic war auch noch viel spaeter in PS/2-Systemen (nein, nicht Playstation 2) von IBM vorhanden. Es liess sich aktivieren, indem man alle Bootmedien deaktivierte oder den Software-Interrupt 0x18 (IIRC) ansprang. Es gab auch die Moeglichkeit auf ein Tape per ROM-BASIC zuzugreifen, allerdings war dieses Entweder nie oder nur optional fuer die allerersten PCs tatsaechlich verfuegbar. --82.141.57.118 16:04, 12. Okt 2005 (CEST)
- Basic war nie tot, aber C++ war (weitgehend) portabel, einfach flexibler und schneller als Basic-Code. Auch das frühe Java war besser als Basic zu seiner Zeit. Basic ist halt was für Datenbank-Frontends (schau Dir mal dBase oder Clipper an) und nicht für Betreibssystemen.--2.200.97.125 22:42, 29. Jan. 2012 (CET)
Mit der Zeit nahm der Anteil der Menschen zu, die einen Computer nur bedienen, aber nicht selbst programmieren mussten. Ein großer Teil der Anwender nutze am Computer nun überwiegend Textverarbeitungen, Tabellenkalkulationen und Datenbanken anstatt selbst die erforderliche Software mit einer Programmiersprache zu entwickeln.
Ein weiterer Grund dafür, dass BASIC zwischenzeitlich fast in Vergessenheit geraten war, war auch, dass nach dem Zusammenbruch der großen Heim- und Bürocomputer-Hersteller Atari und Commodore der Markt von Windows-PCs dominiert wurde. Bei diesen war kein BASIC-Interpreter inbegriffen, mit dem man Windows-Programme hätte selbst schreiben können. (nicht signierter Beitrag von 109.43.109.18 (Diskussion) 06:21, 18. Mai 2012 (CEST))
- Das stimmt aber nicht. QBasic war bis einschließlich Version 6.22 (von 1994) Bestandteil von MS-DOS und danach wurde es als Gratiszugabe auf den Installationsmedien von Windows 95 (1995), 98 (1998) , 98SE (1999) und ME (2000) mitgeliefert. --Rôtkæppchen₆₈ 15:06, 24. Mai 2014 (CEST)
- Das stimmt sehr wohl - bitte den beanstandeten Satz zuende lesen: Es wurde ein DOS-Basic (QBasic) beigelegt, aber niemals ein Basic, mit denen man Windowsapplikationen hätter erstellen können. Un wer auf einem Windows PC damals mit QBasic hantierte, der rüstete auch Supertanker mit Außenbordmotoren aus. 79.212.143.76 06:06, 19. Okt. 2016 (CEST)
Aussagen über Ursachen für zurück gehende Popularität mögen zwar plausibel erscheinen. So lange sie nicht durch zuverlässige Quellen abgesichert sind, sind sie kein Stoff für den Artikel. Die Gefahr von freier Spekulation und Theoriefindung wäre zu groß. ---<)kmk(>- (Diskussion) 01:38, 19. Nov. 2017 (CET)
- Für mich sind zwei (zeitlich und kausal aufeinanderfolgende) Gründe ziemlich augenscheinlich:
- 1. die leider erfolgreiche, denkbar polemische Anti-BASIC-Propaganda durch Edsger W. Dijkstra - Kostprobe: “It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” Die Lächerlichkeit dieser Aussage zeigt sich schon daran, dass die epochalsten Programmierer mit BASIC anfingen, wie Bill Gates, Paul Allen, Steve Wozniak, Linus Torvalds. Dass die frühen Programmier-Titanen kein BASIC für ihre Großtaten (auf Micro-/Personal-Computern) verwendeten, lag schlicht daran, dass zu dieser Zeit noch keine Hochsprache dafür geeignet war, sondern systemnah noch in Assembler programiert werden musste (wobei das meiste, das BASIC vorgeworfen wurde, auf Assembler in noch potenzierter Form zutrifft). Die späteren Titanen mussten C / C++ verwenden - wegen:
- 2. Nach der in die Welt gesetzten und tausendfach nachgeplapperten Verfehmung von BASIC hatte das neben dem Reputationsverlust natürlich auch zur Folge, dass immer weniger Entwicklungsarbeit in BASIC-Compiler floss, stattdessen mehr in C- und C++-Compiler, die dann natürlich irgendwann effizienteren Maschinencode produzierten. Dass die Sprache BASIC als solche aber mindestens funktional gleichwertig ist, zeigt sich an Visual Basic als (bis vor kurzem) einer der Sprachen der der .NET-Plattform oder an der BASIC-Variante QB64, wo der BASIC- erst in C++-Code transformiert und dann mit einem C++-Compiler kompiliert wird - prinzipiell wäre es dann natürlich auch möglich, einen direkt den Ursprungs-Code genau so effizient in Maschienncode umwandelnden BASIC-Compiler zu entwickeln.
- Dijkstra wolte seine strikten Strukturierungs-Dogmen durchsetzen, da war ihm eine Sprache wie BASIC, die eine viel freiere Algorithmen-Findung ermöglicht, natürlich ein Dorn im Auge. Die zwingend strukturierten Sprachen sind für das Denken ein Prokustesbett - ein Dijkstra-Kritiker (der Name ist mir leider entfallen) hat mal empirisch untersucht, dass nach der Ablösung der früheren BASIC-Varianten durch zwingend strukturierte Sprachen die Programmcodes länger, unübersichtlicher und ineffizienter wurden bei längeren Entwicklungszeiten, weil eben alles am intuitiven Denken vorbei in die vorgeschriebenen Strukturen gepfercht werden musste.
- Natürlich hat eine gewisse Strukturiertheit (z. B. lokale Variablen für leicht wiederverwendbare Module) Vorteile - auch die weitere Entwicklung von BASIC hat sich dem nicht verschlossen - aber als Zwang, aus dem nicht aus guten Gründen ausgebrochen werden kann, ist das meines Erachtens ein Gift. Am schlimmsten finde ich zwingend objektorientierte Sprachen - wenn alles auf Biegen und Brechen ein Objekt sein muss, kann das zu grotesk kontraintuitivem Code führen.
- Früher mal galten intuitive Verwendbarkeit und Verständlichkeit als Qualitätsmerkmale einer Programmiersprache - was ja auch in der Logik der chronologischen Entwicklung von rein numerischer Maschinensprache über Assembler zu immer "höheren" Programmiersprachen liegt - das ging mit den Attacken auf BASIC unter. Dass BASIC in der Hinsicht - traurigerweise bis heute immer noch - den Zenit darstellt, zeigt sich zum Beispiel daran, dass auch noch in neueren Büchern, die sprachübergreifend-allgemein ins Programmieren einführen, die ersten Code-Beispiele in BASIC erfolgen. --2A02:8108:8380:3B48:C100:7B35:74C2:527A 02:35, 14. Nov. 2023 (CET)
- Da kann ich zu 100% zustimmen, den Basic(egal ob Zeilenbasiert oder nicht!) ist gar nicht so schlecht wie es leider so oft dargestellt wird. Der inoffizielle Nachfolger von BASIC, damit meine ich PYTHON(Auch ganz OK!) wird mittlerweile mit haargenau den gleichen Argumenten kritisiert wie früher BASIC! Und Spaghetti-Code ist auch in den meisten anderen Programmiersprachen machbar, sogar in Programmiersprachen die als zu 100% strukturiert gelten! --Beonura (Diskussion) 02:15, 7. Feb. 2024 (CET)
Entwicklung der Sprache
[Quelltext bearbeiten]Es gibt im Artikel zwei unterschiedliche Jahresangaben zur Entwicklung der Sprache, 1964 in der Einleitung und später 1963. Es wäre schön wenn das mal jemand überprüfen könnte und ggfls korrigieren, oder wenn dies sich so zeigt 1963-1964 einsetzen könnte. 62.180.131.131 21:29, 13. Okt. 2009 (CEST)
BASIC wurde auf IBM /360 Mainframes Anfang der 70er angeboten. Unter MVS/TSO gab es ~1970/71 sowohl für PLI (abgestripptes PL1) als auch BASIC einen Interpreter. Da es konkurrierend zu PL1 auf den Dialogsystemen (u.a. auch VM) angeboten wurde, hat es wegen des größeren Sprachumfangs von PL/1 auf dem Mainframe "verloren". Unter Systemprogrammierern wurden immer wieder (Mainframe) BASIC-Spiele ausgetauscht, produktiv war es bei großen Firmen m.W. nicht im Einsatz. Zum IBM PC wurde ja bereits geschrieben, Anfangs im ROM, usw.
Literatur zu /360 Mainframe s. http://content.wuala.com/contents/sccosel/mvs380/Vintage_Manuals.html .
Nachtrag TSO: Unter TSO in der Komponente ITF, Literatur s. http://archive.org/stream/bitsavers_ibm360osR2OOptionGuideRel20.1Jun71_13027421/GC28-6698-3_TSO_Option_Guide_Rel_20.1_Jun71_djvu.txt (nicht signierter Beitrag von 79.247.19.4 (Diskussion) 19:47, 7. Okt. 2015 (CEST))
Syntaxfehler?
[Quelltext bearbeiten]Im Listing steht da auf Zeile 80: 80 IF LEN(Q$) = 0 GOTO 70
Ich würde mal sagen, abgesehen von einigen Dialekten wird das vermutlich einen Syntaxfehler liefern.
Es sollte wohl eher 80 IF LEN(Q$) = 0 THEN GOTO 70, also mit "THEN" heissen. --Wurzlsepp 01:08, 9. Feb. 2010 (CET)
- Nein! Man kann ENTWEDER das "then" ODER das "goto" weglassen!--TheRealScot 23:48, 31. Aug. 2010 (CEST)
- Das gilt nur bei den Microsoft-BASIC-Varianten und deren Derivate. Beim Sinclair ZX Spectrum lässt sich der verkürzte Code nicht einmal eingeben. Formal korrekt auf allen Systemen ist die Version mit
THEN GOTO. --Rôtkæppchen₆₈ 15:09, 24. Mai 2014 (CEST)
- Das gilt nur bei den Microsoft-BASIC-Varianten und deren Derivate. Beim Sinclair ZX Spectrum lässt sich der verkürzte Code nicht einmal eingeben. Formal korrekt auf allen Systemen ist die Version mit
Erganzende Links und Literatur
[Quelltext bearbeiten]- Man kann das Handbuch des ersten BASICs von 1964 als PDF-Datei auf der Website Bitsavers.org herunterladen.
- Viele Spiele, die ursprünglich für Grossrechner dieser Zeit geschrieben wurden, wurden für Mikrocomputer in BASIC angepasst. Man kann viele der Listings finden in den Büchern von David H. Ahl: Basic Games, More Basic Games, Big Computer Games.
Die Programme können auch als ZIP-Datei auf der Website http://www.classicbasicgames.org/ heruntergeladen werden.
Microsoft BASIC hatte sich zum de-facto-Standard für das BASIC auf Mikrocomputern entwickelt, aber es gab viele Varianten, die im Dictionary of Basic (Hrsg. PSI, 1984) angesprochen werden (französisch).
In den 1980er Jahren erschienen dann weitere BASICs, wie z.B. das GFA-Basic auf dem Atari ST. Die Spezialität hierbei war, dass nun Zeilennummern eleminiert wurden und die Programmlistings strukturierter wurden. (signierter Beitrag von Kollo (Diskussion | Beiträge) 10:27, 10. Mär. 2010 (CET))
Die Programmiersprache BASIC unter Linux
[Quelltext bearbeiten]Auf Unix-Systemen hatte Basic nie die Popularität, die es auf Kleinst-Computern hatte. Bei UNIX systemen, so auch bei Linux, gab es bereits genug andere Interpreter (sogenannte shells), mit denen man schnell kleinerere Programmieraufgaben erledigen konnte. Allerdings ist die Syntax der meisten Shell-Interpretersprachen viel komplizierter und fuer den Laien ungewohnt. So haben die meisten Linux-Distributionen standardmäßig keinen BASIC-Interpreter vorinstalliert. Dies bedeutet jedoch nicht, daß es keine Interpreter für Linux gibt.
(Quelle der Information in der Tabelle: http://pagesperso-orange.fr/edmond.orignac/basic.html )
Ein Artikel in der Linux Focus vom Januar 2003 stellt BASIC interpreter unter Linux vor, welche damals verfügbar waren, bzw. sich noch in der Entwicklung befanden: XBasic, SmallBASIC, wxBasic, Yabasic, X11-Basic, HBasic, GNOME Basic, KBasic und der Basic-Compiler GNU/Liberty Basic. Nicht alle dieser BASIC Dialekte wurden zuende entwickelt und manche kamen über das ambitionierte Stadium der Ideenfindung und der beta-Versionen nicht hinaus.
- Die Entwicklung von Gnome Basic wurde 2002 eingestellt.
- Die Weiterentwicklung von YaBasic wurde 2007 eingestellt.
- KBasic gibt es ausschliesslich unter linux und erlaubt nur die Entwicklung von open source programmen.
- Die Entwicklung des GNU/Liberty Basic compilers wurde 2002 eingestellt.
- Es gibt noch einen anderen Compiler, Agora Basic, aber das letzte Lebenszeichen stammt von 2006.
Die Entwicklercommunity blieb aussderdem klein, da es zu viele halbfertige Projekte mit unterschiedlichem Sprach-Standard gab. Im Jahre 2010 haben folgende Projekte überlebt, bzw. erfreuen sich einer einigermassen erfolgreichen Anhaengerschaft: X11-Basic (Erfolgreich auch auf linux-basierten Handhgelds und Navigationsgeraeten), Wx-Basic, XBasic, HBasic, Gambas, Chimpunk Basic, Blassic, Basic-256, Vintage Basic, Decimal Basic, Decimal Basic, Bywater Basic, Small Basic, Brandy und bas. Also eine dennoch recht grosse Auswahl, bei der fuer jeden Geschmack bzw. Dialect etwas dabei sein dürfte.
Die Basic Interpreter eignen sich insbesondere auch als Ersatz für eine Shell auf den UNIX Systemen, so dass sie auch die WEB Programmierung (.cgi Scripts) für Laien zugänglich machen. Manche Interpreter offerieren auch die Programmierung von grafischen Elementen, was eine zusätzliche Erleichterung darstellt, da es standardmäßig die kommandozeilen-orientierten Shells nicht ermöglichen, und auch die Grafik-Programmmierung in C mit den verschiedensten Bibliotheken unübersichtlich und schwierig ist. Schließlich spielt sich der Vorteil von Basic immernoch (auf Leistiungsschwächeren mobilen Geräten) aus, nämlich recht wenig Speicher zu beanspruchen.
(nicht signierter Beitrag von Kollo (Diskussion | Beiträge) 11:05, 10. Mär 2010 (CET))
Entwicklung der Sprache
[Quelltext bearbeiten]Da es bei Basic ja keinen wirklichen Standart gibt, fände ich es gut, wenn man so ein Entwicklungsschema einfügen würde. Das heist, eine Übersicht, wie sich die Programmierung von Zeilennummerorientierten unstrukturierten Prgrammmen, zu den strukturierten Versionen von heute entwickelt hat. Am Anschaulichsten währe das ganze anhand von Beispielen (die natülich in alle das selbe tuen). --195.246.108.11 13:52, 5. Jan. 2011 (CET)
Interpretierte oder Compilierte Sprache?
[Quelltext bearbeiten]Mir fehlt da noch die Information, ob BASIC eine interpretierte oder eine compilierte Sprache ist. --DSGalaktos 16:02, 20. Mär. 2011 (CET)
- Wo "da"? Im Artikel insgesamt?
- Zur Sache: Es gibt sowohl Interpreter als auch Compiler von BASIC, die Sprache (besser: Sprachenfamilie) BASIC selbst ist also weder interpretiert noch compiliert. Beispielsweise wurde Atari-Basic auf dem Atari 800XL interpretiert, hingegen wurde und wird PowerBASIC immer compiliert. --Parzi 19:00, 20. Mär. 2011 (CET)
- Ja, im Artikel meinte ich. Sorry. Wenn das so ist, fände ich das schon erwähnenswert. Es wird zwar immer wieder im Artikel sowohl von Interpretern als auch von Compilern gesprochen, man kann es sich also erschließen, aber da das bei heutigen Sprachen ja so gut wie immer feststeht (ich kenne kein Gegenbeispiel), könnte man das meiner Meinung nach auch in der Einleitung sagen. --DSGalaktos 16:25, 21. Mär. 2011 (CET)
- Zwei Sprachen, die sowohl interpretiert als auch compiliert werden sind Python und [[Perl (Programmiersprache)|Perl]. Das sind zwei der populärsten Scriptsprachen überhaupt. Umgekehrt gibt es Interpreter für Pascal, das ursprünglich für Compiler entworfen wurde. Informatiker würden argumentieren, dass man zu jeder Sprache sowohl Interpreter als auch Compiler schreiben kann. So richtig singulär steht BASIC damit jedenfalls nicht dar. -<)kmk(>- (Diskussion) 01:11, 19. Nov. 2017 (CET)
Spaghetticode
[Quelltext bearbeiten]Wo die Unterprogrammtechnik von BASIC um Funktionen und Prozeduren erweitert wurde, konnte häufig auf die zwingenden Zeilennummern und die Sprunganweisung "GOTO" verzichtet werden. Der viel kritisierte sogenannte Spaghetticode, der zu unübersichtlichen Programmen mit überraschenden Spüngen im Quellcode führte, konnte einer strukturierten und funktionsorientierten Programierung weichen. (nicht signierter Beitrag von 109.43.98.230 (Diskussion) 22:27, 5. Okt. 2011 (CEST))
Die Formulierung, dass Spaghetticode zu unübersichtlichen Programmen „führte“, ist in mhererer Hinsicht schlichtweg falsch.
- Spaghetticode führt nicht zu unübersichtlichen Programmen, mit welchem Wort ja auch die laufende Anwendung bezeichnet wird, sondern der Begriff Spaghetticode hat eine engere Bedeutung, gemeint ist der Quelltext, nicht das Programm.
- Spaghetticode führt nicht zu unübersichtlichen Quelltexten, sondern er bezeichnet unübersichtliche Quelltexte. Beispielsweise erläutert der Wikipediaartikel über Spaghetticode: „Jedes verworrene und auch für erfahrene Programmierer schlecht nachvollziehbare Stück Quellcode kann als Spaghetticode bezeichnet werden.“ Spaghetticode führt nicht zu Spaghetticode, Spaghetticode ist Spaghetticode.
--Parzi 00:54, 18. Sep. 2011 (CEST)
Ich finde - als jemand der es seit 1981 mit diversen Basic-Varianten zu tun hatte - alle bisherigen Formulierungen zum Spaghetti-Code nicht genial. Ich vermute, dass ein Nicht-Eingeweihter nicht viel versteht, und würde daher eine Umformulierung in kurze, klare Sätze bevorzugen. -- HubiB 20:58, 18. Sep. 2011 (CEST)
- Die ursprünliche kursive Variante mit einer Erklärung:
Spaghetticode, der zu unübersichtlichen Programmen mit überraschenden Spüngen im Quellcode bezeichnet ist schon brauchbar, da er in Kommas als pptionale Beschreibung (eingefügter Nebensatz) geklammert wurde... Was draus wurde ist leider jetzt nicht besser...--109.43.98.230 22:27, 5. Okt. 2011 (CEST)
Time-Sharing Basic und Selbst-Programmieren
[Quelltext bearbeiten]Große, ernsthafte Bedeutung bekam Basic durch Time-Sharing. Die ersten kommerziellen Rechner hatten sozusagen als Betriebssystem Basic -- etwa HP-Tischrechner, gewiss. Darüberhinaus gab es Time-Sharing-Anschlüsse. Mit einer monatlichen Gebühr und einem Terminal, typisch einem am. Fernschreiber (Teletype, TTY), war man über Modem mit Rechen- und Datenbankleistung verbunden. Fortschrittliche Abteilungen in Buchhaltung oder Forschung waren angeschlossen und programmierten sich ihren Bedarf in Basic. Auswertungen, Ergebnisausdrucke, alles in Basic am TTY mit 10 Zeichen in der Sekunde. Zentral stand ein Minicomputer von Dec (PDP) oder HP (2116). In Amerika, wo tel. Ortsgespräche gratis waren, ein großer Erfolg, in Europa und insbes. in Deutschland bei Minutentakten auf Ortsgesprächen ein teueres Vergnügen. Dazu kam noch, dass die Bundespost fremde Modems verboten hatte, Akustikmodems erst recht, und dass Deutsche im Gegensatz zu Amerikanern ungern selbst programmierten und lieber auf Ruf-Buchhaltung oder Nixdorf setzten, später auf die Datev. Jedenfalls blieb hier der Basic-Kult aus. So, wie hier früher der seriöse Manager keine Tastatur selbst anfasste, programmierte und programmiert immer noch keiner "tiefer" als Powerpoint oder vielleicht noch Excel. Selbst Organizer waren autonom einfach selbst programmierbar (Psion), wo man sich heute Apps holen muss. Schade. -- Fritz@Joern.De Fritz Jörn 14:50, 15. Jan. 2012 (CET)
Belege: Zum 50sten alles Gute
[Quelltext bearbeiten]Hier mal zwei Berichte zum 50sten, die auch gut als (leicht zugängliche) Belege genutzt werden könn[t]en.
- 50 Jahre BASIC: die Allzweck-Programmiersprache für Anfänger feiert Jubiläum – Bericht bei Heise online, vom 1.5.2014
- BASIC: GOTO 50 – Bericht bei Golem.de, vom 1.5.2014
MfG, 92.225.43.58 am 5.5.2014, um 10:04 (MESZ)
unterschwellige Forderung ist Käse
[Quelltext bearbeiten]"Ein großer Teil der Anwender nutzte deshalb nun am Computer überwiegend vorhandene Programme wie Textverarbeitungen, Tabellenkalkulationen und Datenbanken anstatt selbst die erforderliche Software mit einer Programmiersprache wie BASIC oder Visual Basic for Applications zu entwickeln."
anstatt selbst zu entwickeln ist für Anwender genauso unhaltbarer POV- Käse wie z.B. anzumerken ein Rennfahrer müsse Kfz entwickeln...--91.34.192.216 16:55, 29. Sep. 2015 (CEST)
- Erledigt --RolandIllig (Diskussion) 12:28, 20. Mär. 2016 (CET)
Unvorhersehbare Funktion von IF-THEN (OR + AND gleichzeitig)
[Quelltext bearbeiten]Ich habe da ein grundsätzliches Problem mit der Anweisung IF-THEN entdeckt, dass scheinbar in allen Arten von Basic auftritt. Es betrifft auf jeden Fall Visual Basic und PHP. Das Problem tritt immer dann auf, wenn man OR (oder) und AND (und) gleichzeitig verwendet. Vielleicht findet sich ja mal eine Stelle in Wikipedia, wo man auf dieses Problem hinweisen kann.
Beispiel: Ein Programmierer möchte die folgende Situation lösen: Wenn eine der beiden Variablen A und B, oder beide gleichzeitig den Wert 1 haben und gleichzeitig C kleiner als 2 ist, dann soll dies als WAHR erkannt werden. Der Code soll also die folgende Tabelle ergeben:
| A | B | C | Ergebnis |
|---|---|---|---|
| 0 | 0 | 1 | UNWAHR |
| 0 | 1 | 1 | WAHR |
| 1 | 0 | 1 | WAHR |
| 1 | 1 | 1 | WAHR |
| 0 | 0 | 2 | UNWAHR |
| 0 | 1 | 2 | UNWAHR |
| 1 | 0 | 2 | UNWAHR |
| 1 | 1 | 2 | UNWAHR |
Der Programmierer scheibt den folgenden Code:
IF A=1 or B=1 and C<2 THEN ...
Tatsächlich liefert dieser Code dann aber das folgende Ergebnis:
| A | B | C | Ergebnis |
|---|---|---|---|
| 0 | 0 | 1 | UNWAHR |
| 0 | 1 | 1 | WAHR |
| 1 | 0 | 1 | WAHR |
| 1 | 1 | 1 | WAHR |
| 0 | 0 | 2 | UNWAHR |
| 0 | 1 | 2 | UNWAHR |
| 1 | 0 | 2 | WAHR |
| 1 | 1 | 2 | WAHR |
Ich weiß leider nicht in welcher Form und auf welchen Artikeln man auf dieses Problem hinweisen könnte. --77.21.163.85 13:12, 27. Jan. 2021 (CET)
- Tatsächlich tut der Code genau das, was er soll. Da das AND stärker "bindet" als das OR wird der Code wie folgt abgearbeitet:
IF A=1 or (B=1 and C<2) THEN ...- Es wird also dieses Statement immer wahr sein, wenn A=1(wie in den letzten beiden Zeilen der Tabelle) oder, wenn B=1 UND C<2. Da ich mich nicht mit Basic auskenne, weiß ich nicht, wie eine korrekte Umsetzung deines Problemes aussieht, aber hier besteht auf jeden Fall kein grundlegender Fehler in Basic ansich.
- --2003:DB:9F0F:B900:8D88:BA1F:9AC3:CF8E 23:01, 23. Mär. 2021 (CET)
Anonyme Änderungen (Benutzer 2003:c3:6727:db00:9566:a788:324f:9118)
[Quelltext bearbeiten]Änderung vom 5. Juli 2022, 03:51 Uhr
[Quelltext bearbeiten]Begründung des Autors: "Mittlerweile ist das falsche Wort für etwas, dass vor allem vor 35 bis 30 Jahren stattfand."
alt: "Mittlerweile gibt es eine Vielzahl verschiedener BASIC-Dialekte, von denen einige der jüngeren alle Elemente höherer Programmiersprachen aufweisen..."
neu: "Ende der 1980er und Anfang der 1990er Jahre entstand eine Vielzahl verschiedener BASIC-Dialekte, von denen einige alle Elemente höherer Programmiersprachen aufweisen..."
kontra: Den Satz würde ich ehrlich gesagt nicht ändern. Es stimmt zwar, dass in den 80er und 90er Jahren viele BASIC-Dialekte entstanden sind, allerdings entstehen auch noch im neuen Millennium (also "Mittlerweile") einige Dialekte (z. B. B4X, XOJO oder VB.NET). Gerade diese Generation beinhaltet Konzepte wie Objektorientierung, Polymorphismus, Try-Catch-Konstrukte etc., während die Dialekte aus den 80er und 90er Jahren noch auf "traditionelle" Konzepte setzte. Beispiel: VB98 nutzte noch On Error Goto statt Try-Catch in VB.NET.
Fazit: "Mittlerweile" passt schon. BASIC ist keinesfalls tot. Im Juli 2022 liegt VB.NET mit 4.97% Marktanteil auf Platz 6 im TIOBE-Index; VB <= 98 mit 1,07% immerhin noch auf Platz 13.
Vorschlag: "Der Großteil der BASIC-Dialekte entstand Ende der 1980er und Anfang der 1990er Jahre. Mittlerweile gibt es eine Vielzahl verschiedener BASIC-Dialekte, von denen einige der jüngeren alle Elemente höherer Programmiersprachen aufweisen..."
Änderung vom 5. Juli 2022, 04:04 Uhr
[Quelltext bearbeiten]Begründung des Autors: "Außerdem gibt es keinen Zeilennummernspeicher, das ist wieder ein Wiki-Märchen, Zeilennummer stehen im Programm-Bytestrom. 2 Byte Zeilennummer, 1 oder 2 Byte Länge, Befehl, Doppelpunkt, Befehl, ..., 00h, nächste Zeile."
alt: "Eine solche Schreibweise hat allerdings kaum Vorteile. Die Verarbeitungsgeschwindigkeit erhöht sich nicht und einzelne Befehle innerhalb einer solchen Zeile haben keine Sprungadresse. Auch die Lesbarkeit von solchem Code ist schlecht. Einzig bei einigen eingeschränkten Systemen mit nur kleinem Zeilennummernspeicher ermöglicht diese Methode größere Programme, die sonst mehr Zeilen benötigen, als das System zur Speicherung zur Verfügung stellt."
neu: "Eine solche Schreibweise hat allerdings Vorteile. Die Verarbeitungsgeschwindigkeit von Sprüngen erhöht sich erheblich (Ausführungszeit ~ Anzahl der Zeilennummern bis zur gewünschten Zeilennummer) und des wird Speicherplatz gespart (5 Byte für jede Zeile vs. 1 Byte für den Doppelpunkt). Auch die Lesbarkeit von solchem Code ist schlecht."
Fazit: In beiden Fällen wäre eine ein Beleg für so eine starke resp. wertende Aussage (Vorteil/Nachteil) nicht verkehrt.
Änderung vom 5. Juli 2022, 04:31 Uhr
[Quelltext bearbeiten]Begründung des Autors: "Ich hätte gern Primärquellen für diesen Abschnitt. Klingt wie eine Dichtung."
Punkt: Erweiterbarkeit der Sprache für Experten
Frage: "Wie soll das gegangen sein?"
Antwort: Das Verfahren nennt sich Bootstrapping. Der Interpreter oder Compiler ist in seiner eigenen Sprache geschrieben. Man spricht auch vom Henne-Ei-Problem. In der Regel findet die Entwicklung in mehrere Iterationen statt.
Beispiel: BASICO - Programming Language, Self-compiling compiler, Der C++ Compiler GCC
Fazit: Statt von Experten zu reden, könnte man auch gleich entsprechende Verfahren nennen.
Punkt: Betriebssystemunabhängigkeit
Feststellung: "BASIC war häufig das Betriebssystem."
Anmerkung: Das geht etwas am Thema vorbei. Der Punkt ist, dass die Rahmenbedingungen eines BASIC-Dialekts unabhängig vom Betriebssystem gelten sollen. Also dass die Datentypen unter unterschiedlichen Systemen gleich groß bleiben; auch die Bit-Reihenfolge; oder auch die Fehler-Konstanten für gleiche Ursachen unter unterschiedlichen Plattformen. Beim klassischen VB sieht man es bezüglich der Datentypen recht gut: so ist der Integer immer 16 Bit gewesen, egal ob 16 Bit OS, 32 Bit OS oder 64 Bit OS (VBA 7). In C ist das nicht so. Dort ist der int Datentyp vom OS abhängig. Für spätere Programmiersprachen bzw. Laufzeitumgebungen (Java oder .NET) werden diese Konventionen durch eine Zwischenschicht (VM) sichergestellt, die das zugrunde liegende Betriebssystem und dessen Eigenheiten abstrahiert. --Siegbert v2 (Diskussion) 18:22, 3. Aug. 2022 (CEST)
Strukturierte Programmierung
[Quelltext bearbeiten]Zum Abschnitt "Programmierbeispiel". Dort steht: "... Dadurch war der Programmierer gezwungen, unstrukturiert zu programmieren ..." Das ist m.E. nicht ganz richtig. Programmiersprachen, die strukturierte Programmierung unterstützen, wie bspw. Python oder Zig, zwingen den Programmierer zur Struktur. Das Ur-BASIC zwang jedoch nicht dazu, unstrukturiert zu programmieren. Strukturiert zu programmieren war natürlich nicht in dem Ausmaß möglich, wie bei einer strukturierten Programmiersprache und auch viel schwieriger, weil alle Struktur vom Programmierer selbst kommen musste und der Zwang zu Zeilennummern jede Änderung an (labellosen) Unterprogrammen zur Qual machte. Unterprogramme waren eben einfach ein Stückchen Code mit einer REM-Zeile als Überschrift. Früher oder später fand man den Weg zur Struktur weil sich ein großes Programm aus Spaghetticode, ebenso wie das Chaos, nur von Genies durchblicken lässt. --Illumany (Diskussion) 19:16, 29. Jul. 2023 (CEST)
- Auch wenn es seltsam klingt, ich finde das BASIC mit Zeilennummern besser und auch logischer ! !! --Beonura (Diskussion) 02:25, 7. Feb. 2024 (CET)