The point is to take APIs that don't and wrap them with said classes, not to provide an alternative.

What percentage of browsers in use implement Proxy and Promise classes? 40 percent?

Per Can I Use [1], promises are in 74% of browsers (only current major browser not supporting them is IE11) and proxies are in 57% of browsers.

Promise is pretty easily polyfilled for older browsers; proxies are more problematic and I don't know whether or not any of the existing proxy polyfills will work with Allora.

[1] http://caniuse.com/

The data behind their world wide browser stats is questionable. - their combined IE and Edge market share totals to only 8%.

On https://www.netmarketshare.com combined IE market share is 31% and Edge is 5%.

What about IE8-10? I agree with pythonistah, that can-i-use data doesn't really map to real-world usage.

Perhaps they only collect data from browsers hitting their web site?

you got it, there are many libraries on npm doing the same but none was build with less than 50 lines of code

The line numbers in BASIC were arbitrary. People often started at higher numbers and jumped by 10 in case they had to put code or comments before or between lines.

Could line numbers be out of order? Like, if I did this:

    10 PRINT "1"
    30 PRINT "2"
    20 GOTO 10

What would print out? Just a bunch of "1"s or "12"s?

It would only print "1"s.

The thing is that basic programs were not entered through a 2D text-editor per rather line per line. You would type "LIST" to re-read the whole program you typed so far, with the lines in the correct order. Then, you would enter a line starting with a number. It would overwrite any existing line with the same number.

Typically, a way to correct the program you wrote would be to type:

30

15 PRINT "2"

(replace the line 30 by an empty line, and insert a line number 15)

Just to add that some BASIC dialects had a RENUMBER or RENUM command that would change all line numbers and references to use a consistent interval. Without that, programs could become hard to modify due to the "gaps" between the lines closing-up.

Couldn't you just increment by 100? Or even 1000? Why did everyone use 10? Was it some interpreter limit that didn't allow line numbers above a certain amount (like 2^15 on a 16-bit CPU)?

Providex (a basic dialect that my company still uses) has a soft-ish limit of around 52000 for line numbers.

You can get around that with some flags, but its more of a pain than its worth.

We tend to go by hundreds for programs, and we have a renumber command, but using it is the nuclear option because it will break goto line number references from outside programs (yeah, that's a very common thing in this language)

I'm curious, is there a specific use case for using such a language today? Is it just legacy?

Mostly legacy.

The main application is decades old, and Providex provides a database of sorts, the language/runtime, a GUI toolkit, and the ability to run on windows, linux, and as a web app (you can use a "desktop" application written in providex in the browser, a great idea in principle, but with the cost of each user license of the language becomes cost prohibitive really fast).

So while everyone agrees that providex needs to go, that would mean replacing just about every single aspect of the company's core application GUI, language, database, even simple-ish things like the editor we use (which is built into the language) all need to be replaced. It's not an easy task.

We've started moving away, but it's going to take a lot of time, and a ton of effort. Right now we are still relying on the providex db stuff pretty much across the board (although i'm launching a new node.js+postgresql server in the next month or so), and we are slowly moving our hosted applications to more traditional web languages (we have some PHP, a bunch of javascript, and a little python).

But the language hurts. It is a combination of compiled and interpreted, so unless you jump through hoops files are saved in a binary format, and you can only use their editor. This also locks us into SVN as our source control, as it's the only VCS that providex supports (and even then, it's pretty bad support). There is virtually 0 tooling, nothing is open sourced, and it's really expensive. It's impossible to remove old code as there is 0 safety, any line can be GOTO'd or GOSUB'd by any other program at any time, and while new programs don't do that, the old programs that do are the ones that you want to refactor but can't. There are also programs where we are out of line numbers and need to resort to GOSUB "hacks" to add a line.

But it's not all bad. Being able to use a "drag and drop" visual editor to make a screen that will work on windows, linux, and the web is pretty nice, and having the DB so tightly coupled means stuff like upgrades/downgrades are pretty simple and don't involve multiple systems. It's also a pretty capable language all things considered (it has classes/objects, it's not as slow as i thought it would be, and it runs on anything without any modification).

For a long time it was still a useful teaching language. On how many languages can you simply make two statements and have a line drawn on the screen?

SCREEN 9

LINE (100,100)-(200,200)

I only know processing that has this kind of ease of use. But any curious kid, given a BASIC interpreter and the LINE instruction will start drawing stuff around, naturally come to loops, and so on, without having to worry about the details of "real" programming languages.

Certainly, it would in part depend on the support of the interpreter, though. Realistically, incrementing by 10 was easy, and if you really needed more you could use goto to jump down and back (though obviously that's not nice for readability).

I remember there being a STEP command to set the increment value. However, when I tested it (on the PCJS sim from the top of the thread) just now, its throwing a Syntax Error!! I am nearly sure that was what the command was, but I don't know what gives right now.

My BASIC memories are rusty, and more oriented toward Applesoft than Microsoft. But I remember STEP being used to give an optional increment to the FOR statement, rather than setting a line numbering increment - for example, you might

    FOR i$ FROM 1 TO 10 STEP 2
    PRINT i$
    NEXT

and get back 2, 4, 6, 8, 10, each on its own line.

I don't remember a command to set the increment for line numbers, but that may be because I never used a BASIC which didn't either require a number on every line or not care about line numbers except as targets for GOTO and similar.

Which is one cause of the spaghetti:

    17 GOSUB 5500

If you typed those lines, then issued a

    LIST

command, the interpreter would return

    10 PRINT "1"
    20 GOTO 10
    30 PRINT "2"

You don't have to type LIST to reorder the lines, that just shows the re-ordering to you. If you didn't type LIST, but did type RUN (with the "unordered" listing) the interpreter would run each line in sequence of line number.

If you ran out of line numbers you could sometimes RENUMber the listing.

Here's Stackoverflow:

This question is marked as a duplicate: http://stackoverflow.com/questions/2435488/why-basic-had-num...

Here's the closed question it's marked as a duplicate of: http://stackoverflow.com/questions/541421/why-did-we-bother-...

It gets run in the correct order. Think of each line as a command that stores the instruction immediately at that line number. You could actually "re-type" a line later by reusing the same line number but replacing it with new contents.

"Correct" order is ambiguous to someone asking that question in the first place.

It sounds like he's saying the "line number" is just the index to a tokenized list (i.e. line 15 is at `lines[15]') where unused lines are just nops. So my "program" would be tokenized and the lines stored like:

    char** lines = malloc(...);
    lines[10] = &line1;
    lines[30] = &line2;
    lines[20] = &line3;

Then when executing, it starts at `lines[0]', sees nops, gets to `lines[10]' and runs it, sees more nops, gets to `lines[20]' and jumps to `lines[10]'. All the while ignoring `lines[21]' and up.

Usually in 8-bit BASICs the lines would be stored consecutively (not in separate malloced segments) with each line starting with its line number. Yes, this meant that GOTO required a search. Memory was a really central design constraint on these systems. I don't know how closely MS's BASICA on the PC followed this model, but the PC's starting configuration had 16k bytes of RAM.

Here's a description of the file format used by BBC Basic:

http://xania.org/200711/bbc-basic-v-format

That's Basic V, which was the variant used on the ARM-based Archimedes, but it's the same file format as the 6502 machine Basics.

Note that the line numbers used by GOTO and GOSUB were specially flagged --- this was so the RENUMBER command could find them. It also meant that computed gotos weren't renumbered...

(Of course, BBC Basic had proper named procedures and functions with local variables, but all self-respecting Basics had to support GOTO and GOSUB.)

Spot on - so line 30 would never get executed on that code, and a series of '1's will get printed, in an endless loop, until stopped with a Ctrl-C.

What is "correct order"? You forgot to answer the actual question.

Sorry, it was ambiguous. I assumed the writer of the original code intended to execute them in the order of the line numbers and that was the "correct order". Otherwise, the line numbers are meaningless.

Not an especially valuable comment from me here, but the fact that people who are probably very technically literate can ask this question makes me feel really rather old.

I remember explaining line-number based BASIC to a younger programmer once and he really couldn't get his head around the idea of GOTOs and GOSUBs based on line numbers -- "why wouldn't you just define functions?"

I remember the minor shock I experienced when writing programs without line numbers. I recall a couple of "good at programming whiz kids" never could make the transition and dropped the compsci major.

I escaped the "permanent brain damage" that Dijkstra complained about that era of BASIC producing, but I understand where he's coming from now and don't begrudge him the slight hyperbole. It was a language where there were so many accidental complexities that there was virtually no prayer of someone penetrating through to the essential issues, using Fred Brook's definitions of accidental/essential. You're not learning anything useful while you're manually renumbering lines because you used up everything between 15-20 and fixing up the GOTOs. (I never had anything with RENUM support.)

It would print out a series of 1s. It is the same as if you had entered

10 PRINT "1" 20 GOTO 10 30 PRINT "2"

The reason this is allowed is because it let you rewrite existing programs; if you later entered

10 PRINT "Hello World"

It would replace the original line 10 and use this one instead.

Well noted. I recall there also used to be a STEP command in the basic interpreter (basica and gw-basic) with which the line number increment could be set e.g. STEP 5 will auto-increment the line numbers by 5. (The default used to be 10.)

The parentheses-less javascript dialect in the title of this HN article relies on ES6 and uses 6 characters:

    !+[]`$

The parent link above is ES5 and uses 8 characters:

    !+[](){}

The jsfuck.com ES6 dialect uses 6 characters:

    !+[]()

jsfuck was previously ES5 but they now rely on ES6isms to shorten their code.