PureBasic switches to a C backend(purebasic.fr)
purebasic.fr
PureBasic switches to a C backend
https://www.purebasic.fr/blog/?p=486
66 comments
Wouldn't Lazarus be a better option in most cases? No silly 800 line limitation, more powerful language, at least as portable etc.
There is a lot of nostalgia with BASIC I suspect but I agree.
Ahh the VB vs Delphi War..... That brings back memories.
I agree that Lazarus looks more mature, however shifting to a pure C backend would actually allow them to be more portable as I believe Lazarus uses FPC which can use a LLVM backend. While LLVM supports most modern platforms, there are lots of less popular architectures that lack LLVM support.
Personally I never liked using any basic derived language for "Real work", but not sure if that was because I was a Delphi guy.
I agree that Lazarus looks more mature, however shifting to a pure C backend would actually allow them to be more portable as I believe Lazarus uses FPC which can use a LLVM backend. While LLVM supports most modern platforms, there are lots of less popular architectures that lack LLVM support.
Personally I never liked using any basic derived language for "Real work", but not sure if that was because I was a Delphi guy.
The list of supported platforms for FPC is pretty impressive[0], whereas LLVM support in FPC appears to be very new, and FPC has very limited platform support using LLVM anyways[1]. LLVM really means nothing for FPC's portability story at this point, as far as I can tell.
I'm skeptical that targeting C opens up any meaningful additional platform support beyond what FPC natively supports. Even relatively new and/or niche architectures like RISC-V and Xtensa appear to be supported by FPC.
(C code also isn't perfectly portable by any stretch of the imagination, so just having some random C compiler for your platform of choice and some emitted C code doesn't really guarantee that you'll end up with a compatible, working solution.)
I've never used Lazarus or FPC beyond just opening it up and playing with it in years past, but it is interesting how much that ecosystem seems to offer.
[0]: discussed in the first paragraph here: https://www.freepascal.org/
[1]: https://wiki.freepascal.org/LLVM#Progress
I'm skeptical that targeting C opens up any meaningful additional platform support beyond what FPC natively supports. Even relatively new and/or niche architectures like RISC-V and Xtensa appear to be supported by FPC.
(C code also isn't perfectly portable by any stretch of the imagination, so just having some random C compiler for your platform of choice and some emitted C code doesn't really guarantee that you'll end up with a compatible, working solution.)
I've never used Lazarus or FPC beyond just opening it up and playing with it in years past, but it is interesting how much that ecosystem seems to offer.
[0]: discussed in the first paragraph here: https://www.freepascal.org/
[1]: https://wiki.freepascal.org/LLVM#Progress
Does FPC/Lazarus have any kind of commercial backing by companies? Honestly the amount of platforms they support is pretty impressive, yet it remains pretty obscure.
The only other project I can think of which remains relatively unknown but still manages to chug along is Tcl (supported by Flightaware and a bunch of other companies iirc).
The only other project I can think of which remains relatively unknown but still manages to chug along is Tcl (supported by Flightaware and a bunch of other companies iirc).
I'm not sure what kind of commercial backing FPC or Lazarus have, if any. As I mentioned, I've never actually used it for anything serious, so I can't really speak to how good it is.
Yeah, there are a lot of relatively unknown projects that keep going. Pharo (a smalltalk inspired language) is another example of such a thing that I've also never used.
Yeah, there are a lot of relatively unknown projects that keep going. Pharo (a smalltalk inspired language) is another example of such a thing that I've also never used.
harbour, a open source clone of xbase/clipper language, targets vanilla C and can run on very different platforms, from msdos to android.
on windows, several c compilers are supported, from pelles to bcc to gcc to intel...
it works.
it works.
> several c compilers are supported
Which is completely different from assuming that emitted C automatically compiles and runs fine under any C compiler under the sun on any target platform, which seemed to be the implied assumption made by the person I was replying to. I definitely could have misinterpreted.
Regardless, my main point is that FPC already seems to support… pretty much everything, which is impressive. They’ve clearly done a lot of work on portability over the years.
Which is completely different from assuming that emitted C automatically compiles and runs fine under any C compiler under the sun on any target platform, which seemed to be the implied assumption made by the person I was replying to. I definitely could have misinterpreted.
Regardless, my main point is that FPC already seems to support… pretty much everything, which is impressive. They’ve clearly done a lot of work on portability over the years.
C is an ISO standard. That's how it works when you code to the standard.
I wish C were that simple and well defined.
The C standard leaves a lot of UB/implementation specific behavior. Fully “standards-compliant” code that works on one compiler may behave in unexpected ways under another compiler, just due to differences in UB handling. And no, it is not trivial to write UB-free C code. Let’s say you are generating C code from your own programming language. Did you know that an infinite loop that doesn’t do anything might be ignored?[0] This materially changes the behavior of the input program in ways that most people wouldn’t expect. C can quickly go from “infinitely portable assembler for my cool new language” to “major source of confusion.”
That’s before even discussing compiler bugs, which will unintentionally break all assumptions of well-behaved code. Rust has run into (and submitted fixes for) so many LLVM bugs over the years that caused silent miscompilation. Complex software tends to have bugs somewhere, and a lot of compilers are complex.
The less trivial the C code, the more likely you are to run into compatibility problems between compilers. “Hello world” should reliably work everywhere, so that’s something… I guess.
But that’s just like… my opinion. If generating arbitrary C code and shoving it through arbitrary C compilers works reliably for you, then that’s cool?
I personally would want to see a large battery of tests that ensures the program code is likely to be working under each new compiler.
[0]: https://stackoverflow.com/questions/59925618/how-do-i-make-a...
The C standard leaves a lot of UB/implementation specific behavior. Fully “standards-compliant” code that works on one compiler may behave in unexpected ways under another compiler, just due to differences in UB handling. And no, it is not trivial to write UB-free C code. Let’s say you are generating C code from your own programming language. Did you know that an infinite loop that doesn’t do anything might be ignored?[0] This materially changes the behavior of the input program in ways that most people wouldn’t expect. C can quickly go from “infinitely portable assembler for my cool new language” to “major source of confusion.”
That’s before even discussing compiler bugs, which will unintentionally break all assumptions of well-behaved code. Rust has run into (and submitted fixes for) so many LLVM bugs over the years that caused silent miscompilation. Complex software tends to have bugs somewhere, and a lot of compilers are complex.
The less trivial the C code, the more likely you are to run into compatibility problems between compilers. “Hello world” should reliably work everywhere, so that’s something… I guess.
But that’s just like… my opinion. If generating arbitrary C code and shoving it through arbitrary C compilers works reliably for you, then that’s cool?
I personally would want to see a large battery of tests that ensures the program code is likely to be working under each new compiler.
[0]: https://stackoverflow.com/questions/59925618/how-do-i-make-a...
I understand what you say but FPC and Harbour just show that writing portable c code is actually possible...
https://github.com/harbour/core#supported-platforms-and-c-co...
https://github.com/harbour/core#supported-platforms-and-c-co...
I have never met a "line limitation". I would have noticed: I have been using PureBasic for 20 years.
You must be speaking of the demo version.
You must be speaking of the demo version.
For anyone still interested in 'Visual Basic' style application development, or for RAD development in general, take a look at Gambas: http://gambas.sourceforge.net/en/main.html
Gambas is a mature, current-generation OO BASIC, has a vast array of libraries, a JIT and is completely open source software.
Gambas is a mature, current-generation OO BASIC, has a vast array of libraries, a JIT and is completely open source software.
And only available on Linux right?
You can run Gambas and Gambas apps on Windows:
https://forum.gambas.one/viewtopic.php?t=812
https://forum.gambas.one/viewtopic.php?t=812
No, work's on all the BSD's too.
As a "big flat file" -- does that mean things like PB_MessageRequester(), SYS_InitString(), etc., are also in the source code, or in a source library? If the source for those aren't included, then it's not really portable beyond the platforms it already supports.
They could still have cross-platform versions of the same library and choose which to use at the linking phase.
I'm sure they do, for the platforms they already support. But the blog post talks about using the C code to run on other platforms. I don't think there's a library for my ppc64le workstation.
PureBasic is one of the best things in life (if I may express my view).
--
The switch from FSAM to GCC slows down the compilation time. What about the compiled software speed?
Edit: the linked post is a few months old. In a later post, Fred (Laboureur) mentions an example of a +50% speed increase.
--
The switch from FSAM to GCC slows down the compilation time. What about the compiled software speed?
Edit: the linked post is a few months old. In a later post, Fred (Laboureur) mentions an example of a +50% speed increase.
They could use the Tiny C Compiler if compile speeds become a concern, although it supports far few platforms and generates much slower code.
What is your use case for BASIC?
I fondly remember Visual Basic 6 as one of the best general purpose development tools for Windows I have ever seen.
As to the “use case”, it still seems like a nice interpreted language for tiny computers based on microcontrollers and for embedded platforms in general.
As to the “use case”, it still seems like a nice interpreted language for tiny computers based on microcontrollers and for embedded platforms in general.
20 year developer here who's touched many many different software stacks.
Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
> Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
People seem to say this a lot but I don't really understand it, because if you use c# with winforms in visual studio it's basically the same thing but better.
People seem to say this a lot but I don't really understand it, because if you use c# with winforms in visual studio it's basically the same thing but better.
Depends on the domain. C# is undoubtedly a lot more powerful and C# runs faster, but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program.
Visual Basic had its warts. C# is a better language from an academic perspective. But VB filled a niche that nothing else has come close to: it made desktop application software writing ridiculously quick and easy. While still being maintainable, readable, and fun.
Electron is probably the closest thing we have to that in the desktop world these days but somehow that performs even worse than VB6 did. Python or Go is probably the most analogous, if you think about command line programs.
Visual Basic had its warts. C# is a better language from an academic perspective. But VB filled a niche that nothing else has come close to: it made desktop application software writing ridiculously quick and easy. While still being maintainable, readable, and fun.
Electron is probably the closest thing we have to that in the desktop world these days but somehow that performs even worse than VB6 did. Python or Go is probably the most analogous, if you think about command line programs.
> but your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program
Not actually true. I just created a new C# Windows Forms application in VS, dragged a button onto a form, double clicked and it took me right to the event handler ready for me to do something. There's no additional boilerplate or ceremony required.
Now sure there may be a whole bunch of code sitting in the "Form1.Designer.cs" partial class, but that's for the designer to manage, not you. And VB had this as well but the VB environment hid this until you went looking for it.
Writing Windows Forms apps in C#/VS2019 is as easy as it was back in the VB5/6 days. I say this as a former VB4/5/6 (and, cough, ahem, MS Access) user knocking out all sorts of stuff back in the 90's.
Not actually true. I just created a new C# Windows Forms application in VS, dragged a button onto a form, double clicked and it took me right to the event handler ready for me to do something. There's no additional boilerplate or ceremony required.
Now sure there may be a whole bunch of code sitting in the "Form1.Designer.cs" partial class, but that's for the designer to manage, not you. And VB had this as well but the VB environment hid this until you went looking for it.
Writing Windows Forms apps in C#/VS2019 is as easy as it was back in the VB5/6 days. I say this as a former VB4/5/6 (and, cough, ahem, MS Access) user knocking out all sorts of stuff back in the 90's.
There’s more to writing software than just dragging a button onto a form ;) at some point you’re going to want to write your own classes, or manage the existing automatically generated ones.
I’ve written sizeable software in both VB6 and C# (both professionally too) and yes, what I said is true about C# being a more verbose language. This isn’t intended as a criticism of C# either. It’s just a natural side effect of C# giving the developers more control.
Plus there’s also a C vs ALGOL type argument with regards to which is easier for a newbie to read and write. C# might produce highly readable code to those already familiar with C-syntax but VB6 is ostensibly executable pseudocode. That alone counts for a lot when talking about the accessibility of programming languages.
I’ve written sizeable software in both VB6 and C# (both professionally too) and yes, what I said is true about C# being a more verbose language. This isn’t intended as a criticism of C# either. It’s just a natural side effect of C# giving the developers more control.
Plus there’s also a C vs ALGOL type argument with regards to which is easier for a newbie to read and write. C# might produce highly readable code to those already familiar with C-syntax but VB6 is ostensibly executable pseudocode. That alone counts for a lot when talking about the accessibility of programming languages.
> There’s more to writing software than just dragging a button onto a form
Clearly, but that wasn't my point. C# isn't a more verbose language, if anything it's more concise. My point was to refute your assertion that "your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program"...which isn't true.
The C vs ALGOL type argument doesn't really stand up for me. I have junior devs on my team who've arrived straight out of bootcamps, college, self-taught etc with a broad spectrum of shallow language skills (PHP, VB, VBA/Script, Java, Javascript), and none of them have trouble dropping into C# world when they've never used it before. C# isn't any more difficult to learn than VB or PHP. Getting up to speed with the .NET framework is a much larger challenge for them than picking up C#.
Clearly, but that wasn't my point. C# isn't a more verbose language, if anything it's more concise. My point was to refute your assertion that "your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program"...which isn't true.
The C vs ALGOL type argument doesn't really stand up for me. I have junior devs on my team who've arrived straight out of bootcamps, college, self-taught etc with a broad spectrum of shallow language skills (PHP, VB, VBA/Script, Java, Javascript), and none of them have trouble dropping into C# world when they've never used it before. C# isn't any more difficult to learn than VB or PHP. Getting up to speed with the .NET framework is a much larger challenge for them than picking up C#.
I think we are going to have to agree to disagree on this.
But FYI, VB6 isn’t .NET. You might be thinking of VB.NET. And if you were, your arguments would be correct. VB.NET is an utterly pointless language. But VB6 is a different beast entirely (and predates .NET by several years)
But FYI, VB6 isn’t .NET. You might be thinking of VB.NET. And if you were, your arguments would be correct. VB.NET is an utterly pointless language. But VB6 is a different beast entirely (and predates .NET by several years)
I know exactly what the differences are between VB5/6 and VB.NET and also saw the futility of adopting VB.NET for greenfield projects. I am no spring chicken.
In the 90's I was neck deep in the land of COM/DCOM and CORBA. Our proof of the pudding, for the stuff we were building to talk to CORBA endpoints, was whether our VB5/6 apps could consume our bridge libraries and start passing sane data backwards and forwards with some janky J2EE horror show. And then we did the same with .NET1 (beta) via COM Interop to those libs etc etc. This is why I know the subject matter well, even if it is 20+ years ago.
Anyhoo, that's my appeal to authority, but I'll agree to disagree.
In the 90's I was neck deep in the land of COM/DCOM and CORBA. Our proof of the pudding, for the stuff we were building to talk to CORBA endpoints, was whether our VB5/6 apps could consume our bridge libraries and start passing sane data backwards and forwards with some janky J2EE horror show. And then we did the same with .NET1 (beta) via COM Interop to those libs etc etc. This is why I know the subject matter well, even if it is 20+ years ago.
Anyhoo, that's my appeal to authority, but I'll agree to disagree.
I was a freelancer back then. So worked across several different stacks. VB6 was my goto for RAD. Delphi for performance. Wasn’t keen on C++ back then and the less said about Java (with regards to desktop applications) the better. I remember hating .NET v1 beta but I can’t for the life of me remember why. C# has definitely grown on me since but ironically these days I don’t touch Windows (nor even write GUI applications).
It is sad to think we gave all that up for HTML/CSS/JS. Now, with "modern" tools, it takes a whole village to build and submit a simple form.
Its not HTML/CSS/JS that killed the RAD tools from the 90s/00s - it is security, multi-user and networking.
I remember how quickly you can put together apps and forms using VB6 + visual designer. But security/permissions were mostly based on your Windows account user. I remember an ERP software that hardcoded the MySQL connection string with a god-mode user+password in a config file and relied on Windows permissions that only the ERP software itself (written in Delphi) could open it. User permissions were then encoded in that DB. Basically, one disassembly of the machine and extracting the config file from the harddrive would have allowed you full access to the db.
Today, we use service layers (REST & Co.) to ensure permissions and access - something that would be equally complex when using VB/Lazarus today.
I remember how quickly you can put together apps and forms using VB6 + visual designer. But security/permissions were mostly based on your Windows account user. I remember an ERP software that hardcoded the MySQL connection string with a god-mode user+password in a config file and relied on Windows permissions that only the ERP software itself (written in Delphi) could open it. User permissions were then encoded in that DB. Basically, one disassembly of the machine and extracting the config file from the harddrive would have allowed you full access to the db.
Today, we use service layers (REST & Co.) to ensure permissions and access - something that would be equally complex when using VB/Lazarus today.
I'm not convinced RAD tools couldn't have been made to work with REST services or something else, like SOAP. SOAP probably would've been better for this. As much as I hated the complexity of SOAP, being able to generate clients from a WSDL was pretty cool.
More insane are the younger generations that grew up with the Web, have no idea how productive native tooling can be and then give us Electron based crap.
Using Microsoft's Jview JVM COM-Java integration (this is like '98 time frame) you could more easily run VB 6 apps against Java application servers because you only needed to distribute the client jar to the VB app. Since there was no early binding you didn't need the code you were going to call remotely on the client, it could just download the classes at runtime and use reflection to make the required calls. Drastically reduced any sort of jar/dll hell.
> your use case for BASIC
Answering not really about 'BASIC', but "PureBasic" (it is not the abstract language but the product).
Personally:
Whenever I want to do some fast coding.
And then, in my case, basically all of my personal desktop applications and compiled shell commands. Because really, it is so pleasant to code on it.
In general:
When you want a lightweight, efficient, specialized environment to quickly get things done, in a framework that is close to low-level (memory structures etc.) and want a compiled result.
And about the "BASIC" part: the BASIC implementation of PureBasic is practically not that different from "reasoning in C" (and you can use the C libraries upon need), but the PB libraries and the IDE makes writing comfortable.
I basically never found a better alternative around this concept: light, powerful, fast, low-level, comfortable.
Answering not really about 'BASIC', but "PureBasic" (it is not the abstract language but the product).
Personally:
Whenever I want to do some fast coding.
And then, in my case, basically all of my personal desktop applications and compiled shell commands. Because really, it is so pleasant to code on it.
In general:
When you want a lightweight, efficient, specialized environment to quickly get things done, in a framework that is close to low-level (memory structures etc.) and want a compiled result.
And about the "BASIC" part: the BASIC implementation of PureBasic is practically not that different from "reasoning in C" (and you can use the C libraries upon need), but the PB libraries and the IDE makes writing comfortable.
I basically never found a better alternative around this concept: light, powerful, fast, low-level, comfortable.
Shouldn’t the backend compiler be a configurable option?
Maintaining multiple backends isn't fun.
Running the same C code through different compilers is totally doable though.
Interesting project.
What do you use it for?
What do you use it for?
On the desktop OS, almost everything (but it must be me). Data manipulation, programming "calculator" (suppose you need to compute something, but with loops conditionals and functions), "/usr/bin" commands, desktop widgets (say, the interface to granularly set the brightness on my laptop), desktop applications (really all sort of things here - anything with a GUI).
An example comes to mind of something pending: there is a recorded debate I should listen to, but of the three participants one is a screamer-in-the-mike and another a low-bass-baritone-in-the-distance. Loop through the audio data compressing the "hypnotist" and the "maniac" at similar amplitude levels, using different wave transformations at different times and with continuity, then compile a command for future cases: a task for your swiss-army-knife PureBasic.
In a way, there is a specific spirit behind it: you are given a computer: the most basic, natural thing you want to do it is code on it. PB represents for me "the default coding system that should have come with the OS" - as some computers had decades ago.
An example comes to mind of something pending: there is a recorded debate I should listen to, but of the three participants one is a screamer-in-the-mike and another a low-bass-baritone-in-the-distance. Loop through the audio data compressing the "hypnotist" and the "maniac" at similar amplitude levels, using different wave transformations at different times and with continuity, then compile a command for future cases: a task for your swiss-army-knife PureBasic.
In a way, there is a specific spirit behind it: you are given a computer: the most basic, natural thing you want to do it is code on it. PB represents for me "the default coding system that should have come with the OS" - as some computers had decades ago.
(Off-topic, but if anyone from PureBasic.fr's web team is here, please please please don't use country's flags to represent languages, just put the language name instead - if you want a visually distinctive but recognizable icon then use a wireframe globe icon)
I don't really see the problem for this website, the languages supported are all European, named after the country they're originally from, (with perhaps US English as the odd one out).
Things might start getting confusing in countries like India, of course, but I don't see the problem in this specific case.
I do have a problem with their homepage related to languages though: you can't get from English to Spanish or Italian on mobile without going through some weird state machine of what language makes sense to list next. There's always the option to switch to English, but I can't see Italian or Spanish from every other page.
Things might start getting confusing in countries like India, of course, but I don't see the problem in this specific case.
I do have a problem with their homepage related to languages though: you can't get from English to Spanish or Italian on mobile without going through some weird state machine of what language makes sense to list next. There's always the option to switch to English, but I can't see Italian or Spanish from every other page.
There are countries within Europe where many different languages are spoken.
> I don't really see the problem for this website, the languages supported are all European, named after the country they're originally from, (with perhaps US English as the odd one out).
As a non-American native speaker of English (Australian), I always feel a little bit excluded when I see an American flag used to represent my native language.
I'm not bothered by the UK flag to quite the same extent – can't deny the language originated in England (although maybe one should really use the English flag not the UK one)
But I think the ideal is to drop the flags and just call them by their native names – English, Français, Deutsch, etc. Or use ISO 639 codes – EN(G), FR(A), DE(U), etc. (Non-technical audiences might find the codes unfamiliar, but for a programming language website that shouldn't be a concern.) Nobody is going to feel excluded, even in the slightest, by either of those approaches.
As a non-American native speaker of English (Australian), I always feel a little bit excluded when I see an American flag used to represent my native language.
I'm not bothered by the UK flag to quite the same extent – can't deny the language originated in England (although maybe one should really use the English flag not the UK one)
But I think the ideal is to drop the flags and just call them by their native names – English, Français, Deutsch, etc. Or use ISO 639 codes – EN(G), FR(A), DE(U), etc. (Non-technical audiences might find the codes unfamiliar, but for a programming language website that shouldn't be a concern.) Nobody is going to feel excluded, even in the slightest, by either of those approaches.
> I'm not bothered by the UK flag to quite the same extent – can't deny the language originated in England (although maybe one should really use the English flag not the UK one)
Consider how that comes across for many people in Northern Ireland, among other places. Just because they speak English, it doesn’t mean they want anything to do with the English (or British) flag.
There’s some more discussion on this here:
Flag as a symbol of language - stupidity or insult?
— https://www.irt.org/articles/js173/
Don't use flags to indicate languages!
— https://www.w3.org/International/questions/qa-link-lang#flag...
Flag Problems
— https://www.nngroup.com/articles/flag-problems/
Consider how that comes across for many people in Northern Ireland, among other places. Just because they speak English, it doesn’t mean they want anything to do with the English (or British) flag.
There’s some more discussion on this here:
Flag as a symbol of language - stupidity or insult?
— https://www.irt.org/articles/js173/
Don't use flags to indicate languages!
— https://www.w3.org/International/questions/qa-link-lang#flag...
Flag Problems
— https://www.nngroup.com/articles/flag-problems/
> Consider how that comes across for many people in Northern Ireland, among other places
You'd probably find half of the population (loyalists/unionists) would be fine with the butchers apron, whereas the other half (republicans) would find it an annoyance.
You'd probably find half of the population (loyalists/unionists) would be fine with the butchers apron, whereas the other half (republicans) would find it an annoyance.
USA English and British English are normally distinct in sites that support lots of languages. I think that Australia inherited things like British spelling and is the same? Or are there differences? (Color vs Colour, etc)
No Australian English and British English are different.
For example, British say lorry but Australians say truck. Although on the whole Australian English is closer to British than American, that's one case where the opposite is true. (But the word truck doesn't mean quite the same thing in American English and Australian English – in American English it has a broader sense, in Australian English its sense is somewhat more narrow – Australians and Americans would both call a semi-trailer truck a truck, but what Americans call pickup trucks Australians generally don't call trucks, we call them utes instead – that term is pretty much unique to Australian and New Zealand English)
And in some cases Australian English matches neither American English or British English. For example, Americans say bell peppers and British say sweet peppers, but Australians say capsicums. (Along with New Zealand English, Malaysian English, Indian English, Pakistani English, Bangladeshi English, and Sri Lankan English.)
People need to get away from the idea that there are only two varieties of English, American and British. There are as many varieties of English as there are countries in which English is a major spoken language.
For example, British say lorry but Australians say truck. Although on the whole Australian English is closer to British than American, that's one case where the opposite is true. (But the word truck doesn't mean quite the same thing in American English and Australian English – in American English it has a broader sense, in Australian English its sense is somewhat more narrow – Australians and Americans would both call a semi-trailer truck a truck, but what Americans call pickup trucks Australians generally don't call trucks, we call them utes instead – that term is pretty much unique to Australian and New Zealand English)
And in some cases Australian English matches neither American English or British English. For example, Americans say bell peppers and British say sweet peppers, but Australians say capsicums. (Along with New Zealand English, Malaysian English, Indian English, Pakistani English, Bangladeshi English, and Sri Lankan English.)
People need to get away from the idea that there are only two varieties of English, American and British. There are as many varieties of English as there are countries in which English is a major spoken language.
I'd wager there is greater linguistic diversity between English spoken in Paddington and Merrylands than that of Paddington and the City of London.
I know when folks address a group of people as 'yous' they mean 'you', but as a plural pronoun. When an American chef says bell peppers, they mean capsicums. I'd argue the former is a bigger step than the latter, given that 'you' is a far more common word.
'Australian English' is at best a dialect of British English, though I don't think the differences even amount to that.
Also, I'd be very impressed if a website substituted lorry for truck when I clicked an Australian flag.
I know when folks address a group of people as 'yous' they mean 'you', but as a plural pronoun. When an American chef says bell peppers, they mean capsicums. I'd argue the former is a bigger step than the latter, given that 'you' is a far more common word.
'Australian English' is at best a dialect of British English, though I don't think the differences even amount to that.
Also, I'd be very impressed if a website substituted lorry for truck when I clicked an Australian flag.
> I know when folks address a group of people as 'yous' they mean 'you', but as a plural pronoun. When an American chef says bell peppers, they mean capsicums. I'd argue the former is a bigger step than the latter, given that 'you' is a far more common word.
The plural form yous or youse is very common across many dialects of English – it is found in Ireland, Scotland, England (in particular in Geordie and Scouse), Australia, New Zealand, and some regional dialects of American English (especially Philadelphia)
> 'Australian English' is at best a dialect of British English, though I don't think the differences even amount to that.
Linguists don't agree. Australian and British English are independent dialects. Even the UK contains multiple dialects of English – "British English" generally means just the way Oxbridge graduates, BBC staff, Whitehall mandarins, etc, speak and write. In fact, the UK arguably has more internal diversity in English than most other English-speaking countries – Geordie is a dialect of English, yet at times is barely intelligible to other native English speakers. Languages are usually the most diverse in their country of origin, since the processes of emigration/colonisation/etc tend to greatly reduce that original diversity.
The plural form yous or youse is very common across many dialects of English – it is found in Ireland, Scotland, England (in particular in Geordie and Scouse), Australia, New Zealand, and some regional dialects of American English (especially Philadelphia)
> 'Australian English' is at best a dialect of British English, though I don't think the differences even amount to that.
Linguists don't agree. Australian and British English are independent dialects. Even the UK contains multiple dialects of English – "British English" generally means just the way Oxbridge graduates, BBC staff, Whitehall mandarins, etc, speak and write. In fact, the UK arguably has more internal diversity in English than most other English-speaking countries – Geordie is a dialect of English, yet at times is barely intelligible to other native English speakers. Languages are usually the most diverse in their country of origin, since the processes of emigration/colonisation/etc tend to greatly reduce that original diversity.
I think my basic point here is that the words dialect and language are too coarse to describe two English variants with identical spelling and grammatical systems, but with some minor differences in pronunciation and word usage. Especially, given that they both have a high degree of internal variance (as you quite rightly said).
If you compare the differences between English as spoken in Australia, England, and (even) America to the various dialects spoken in China, you can see how little descriptive value there is in referring to minor English variants as dialects or even independent languages.
Ultimately, the decision to declare a cluster of variations a dialect or separate language, or even admit it exits is a political choice, closely tied to national identity. For instance, there is technically a New Zealand English, but it's essentially identical to Australian English aside from some minor differences in pronunciation.
So, I don't see why people should really care if they see the Australian flag appears in the language menu.
If you compare the differences between English as spoken in Australia, England, and (even) America to the various dialects spoken in China, you can see how little descriptive value there is in referring to minor English variants as dialects or even independent languages.
Ultimately, the decision to declare a cluster of variations a dialect or separate language, or even admit it exits is a political choice, closely tied to national identity. For instance, there is technically a New Zealand English, but it's essentially identical to Australian English aside from some minor differences in pronunciation.
So, I don't see why people should really care if they see the Australian flag appears in the language menu.
> If you compare the differences between English as spoken in Australia, England, and (even) America to the various dialects spoken in China, you can see how little descriptive value there is in referring to minor English variants as dialects or even independent languages.
Well, many linguists consider the different "dialects" of Chinese to be distinct languages, since in their spoken forms they are not mutually intelligible. What makes it more complex is that (a) their written forms can be mutually intelligible even when their spoken forms are not – in this regard the Chinese languages are quite unlike those of Europe or other parts of Asia, where spoken and written mutual intelligibility align much more closely; (b) the Chinese government, for political reasons, wants to promote the viewpoint of "multiple dialects of one language" over the (arguably linguistically more accurate) viewpoint of "a family of distinct but related languages sharing a common writing system", since it fears the later idea may eventually result in the breakup of China into multiple countries along linguistic lines, and thus that viewpoint is seen as a threat to Beijing's rule.
> Ultimately, the decision to declare a cluster of variations a dialect or separate language, or even admit it exits is a political choice, closely tied to national identity
It is true that sometimes questions about what is a language and what is a dialect can be deeply political. Whether Mandarin and Cantonese are separate dialects of one Chinese language, or two distinct languages within the Chinese language family, is a highly political question. Similarly, whether Macedonian and Bulgarian are two different languages, or two different dialects of one language, is a very political question (Bulgarian nationalists say Macedonian is a dialect of Bulgarian, Macedonian nationalists say it is a separate language). The same is true of the relationship between Hindi and Urdu, Serbian and Croatian, Romanian and Moldovan.
But that isn't always true. The question of whether Australian English and New Zealand English are two different dialects or one single dialect is not a subject of passionate political dispute in the way that (e.g) the difference between Bulgarian and Macedonian is. Neither the Australian nor New Zealand government cares much about the question – by contrast, the Chinese government has strong views about the language-vs-dialect question for Chinese.
> For instance, there is technically a New Zealand English, but it's essentially identical to Australian English aside from some minor differences in pronunciation.
It isn't just differences in pronunciation, there are also differences in vocabulary. For example, a portable ice cooler is called an esky by Australians but a chilly bin by New Zealanders. There are occasional spelling differences – Australians (like most other English dialects) usually write fjord, but New Zealanders more commonly write fiord. Another big difference is the widespread use of Māori words and phrases in New Zealand English, even by non-Māori New Zealanders (kia ora, pākehā, whānau, etc). There is even, in a sense, a difference in the alphabet – writing Māori loanwords with macrons (ā, ē, ī, ō, ū – used in Māori to mark long vowels and distinguish them from short ones) is common and accepted in New Zealand English, and in some contexts (such as government documents) is even preferred, whereas doing so in Australian English is rare.
Given all these differences in pronunciation, vocabulary, and occasionally even spelling, most professional linguists consider Australian English and New Zealand English to be two distinct (albeit closely related) dialects. I don't see any evidence that viewpoint is influenced by any political bias. Linguistics can at times be a politically fraught subject, but this particular linguistic question is not a significant political issue in either country.
> So, I don't see why people should really care if they see the Australian flag appears in the language menu.
I have never seen an Australian flag in a language menu. I have seen the US flag, UK flag, even occasionally some hybrid flag which merges the two (like [0]). Nobody creates multiple versions of a website in different dialects of English.
One does sometimes see country flags used to represent different national versions of a website, which will differ in more than just language/dialect, but also stuff like pricing, product range availability, marketing campaigns, etc. I don't think anybody ever objects to that. In this case, the flag is used to represent the country, not the language or dialect, and few object to using flags as representations of countries.
[0] https://commons.wikimedia.org/wiki/File:English_language.svg
Well, many linguists consider the different "dialects" of Chinese to be distinct languages, since in their spoken forms they are not mutually intelligible. What makes it more complex is that (a) their written forms can be mutually intelligible even when their spoken forms are not – in this regard the Chinese languages are quite unlike those of Europe or other parts of Asia, where spoken and written mutual intelligibility align much more closely; (b) the Chinese government, for political reasons, wants to promote the viewpoint of "multiple dialects of one language" over the (arguably linguistically more accurate) viewpoint of "a family of distinct but related languages sharing a common writing system", since it fears the later idea may eventually result in the breakup of China into multiple countries along linguistic lines, and thus that viewpoint is seen as a threat to Beijing's rule.
> Ultimately, the decision to declare a cluster of variations a dialect or separate language, or even admit it exits is a political choice, closely tied to national identity
It is true that sometimes questions about what is a language and what is a dialect can be deeply political. Whether Mandarin and Cantonese are separate dialects of one Chinese language, or two distinct languages within the Chinese language family, is a highly political question. Similarly, whether Macedonian and Bulgarian are two different languages, or two different dialects of one language, is a very political question (Bulgarian nationalists say Macedonian is a dialect of Bulgarian, Macedonian nationalists say it is a separate language). The same is true of the relationship between Hindi and Urdu, Serbian and Croatian, Romanian and Moldovan.
But that isn't always true. The question of whether Australian English and New Zealand English are two different dialects or one single dialect is not a subject of passionate political dispute in the way that (e.g) the difference between Bulgarian and Macedonian is. Neither the Australian nor New Zealand government cares much about the question – by contrast, the Chinese government has strong views about the language-vs-dialect question for Chinese.
> For instance, there is technically a New Zealand English, but it's essentially identical to Australian English aside from some minor differences in pronunciation.
It isn't just differences in pronunciation, there are also differences in vocabulary. For example, a portable ice cooler is called an esky by Australians but a chilly bin by New Zealanders. There are occasional spelling differences – Australians (like most other English dialects) usually write fjord, but New Zealanders more commonly write fiord. Another big difference is the widespread use of Māori words and phrases in New Zealand English, even by non-Māori New Zealanders (kia ora, pākehā, whānau, etc). There is even, in a sense, a difference in the alphabet – writing Māori loanwords with macrons (ā, ē, ī, ō, ū – used in Māori to mark long vowels and distinguish them from short ones) is common and accepted in New Zealand English, and in some contexts (such as government documents) is even preferred, whereas doing so in Australian English is rare.
Given all these differences in pronunciation, vocabulary, and occasionally even spelling, most professional linguists consider Australian English and New Zealand English to be two distinct (albeit closely related) dialects. I don't see any evidence that viewpoint is influenced by any political bias. Linguistics can at times be a politically fraught subject, but this particular linguistic question is not a significant political issue in either country.
> So, I don't see why people should really care if they see the Australian flag appears in the language menu.
I have never seen an Australian flag in a language menu. I have seen the US flag, UK flag, even occasionally some hybrid flag which merges the two (like [0]). Nobody creates multiple versions of a website in different dialects of English.
One does sometimes see country flags used to represent different national versions of a website, which will differ in more than just language/dialect, but also stuff like pricing, product range availability, marketing campaigns, etc. I don't think anybody ever objects to that. In this case, the flag is used to represent the country, not the language or dialect, and few object to using flags as representations of countries.
[0] https://commons.wikimedia.org/wiki/File:English_language.svg
I don’t agree completely.
If the site is localized into de_DE and fr_FR then it makes perfect sense to use the country flags. In more general terms: When the site is localized into the locale of specific country/nation and that country/nation has that language as its only official language.
The official language of Great Britain is English. The various other languages spoken in the countries that are part of UK are regional/local. So using GB flag for locale en_GB is appropriate.
US flag for en_US.
Brazilian flag for pt_BR.
Portuguese flag for pt_PT.
Whereas for example Canada has both French and English as official languages right. So if you are writing for fr_CA or en_CA locales then it would be inappropriate indeed to use Canadian flag (since in that case it doesn’t say which language), and equally wrong to use French or USA flag because those flags imply fr_FR and en_US. So if either fr_CA or en_CA is among your target locales, either use text for everything instead of flags, or use flags for the locales that have them and text for fr_CA and en_CA. Likewise for other countries with multiple official languages.
Australia apparently has no official language at the federal level. So the Australian flag should not be used for en_AU locale. Instead text should be used for en_AU locale.
If the site is localized into de_DE and fr_FR then it makes perfect sense to use the country flags. In more general terms: When the site is localized into the locale of specific country/nation and that country/nation has that language as its only official language.
The official language of Great Britain is English. The various other languages spoken in the countries that are part of UK are regional/local. So using GB flag for locale en_GB is appropriate.
US flag for en_US.
Brazilian flag for pt_BR.
Portuguese flag for pt_PT.
Whereas for example Canada has both French and English as official languages right. So if you are writing for fr_CA or en_CA locales then it would be inappropriate indeed to use Canadian flag (since in that case it doesn’t say which language), and equally wrong to use French or USA flag because those flags imply fr_FR and en_US. So if either fr_CA or en_CA is among your target locales, either use text for everything instead of flags, or use flags for the locales that have them and text for fr_CA and en_CA. Likewise for other countries with multiple official languages.
Australia apparently has no official language at the federal level. So the Australian flag should not be used for en_AU locale. Instead text should be used for en_AU locale.
> Likewise, use GB flag for en_GB locale is cool too, and US flag for en_US. Though with English I suspect many sites may actually not be written in British English and yet they might use GB flag. In that case they are using the wrong flag.
A lot of English text isn't clearly identifiable as belonging to a certain dialect. A single text can be a collaborative work between people using different dialects of English and so different parts of the document can end up being spelled in different ways. Spelling differences aren't always as simple as American vs British – -ize spellings are preferred over -ise in American English, yet -ize spelling is also permitted (if less common) in British English (so-called Oxford spelling). I myself speak Australian English, but in certain contexts (especially talking about computers, or at work – I work for a US-based company) I tend to Americanise my English a little bit. Australian English is neither American nor British – it tends to be closer to British mostly (e.g. petrol not gasoline), but sometimes is closer to American instead (e.g. truck not lorry), and sometimes does its own thing–e.g. Americans say bell peppers and the British say sweet peppers but Australians for some reason use the Latin name capsicum (for the mild ones, not the spicy ones) – which is not unique to Australia, New Zealand and Indian English do that too.
Anyway, we don't need to tag documents with the precise dialect of English. We all understand each other pretty well anyway.
Also, locale != language. Locale is about stuff like date formats, number formats, etc. It is rare for a non-interactive website – as opposed to an interactive webapp - to support multiple locales.
A lot of English text isn't clearly identifiable as belonging to a certain dialect. A single text can be a collaborative work between people using different dialects of English and so different parts of the document can end up being spelled in different ways. Spelling differences aren't always as simple as American vs British – -ize spellings are preferred over -ise in American English, yet -ize spelling is also permitted (if less common) in British English (so-called Oxford spelling). I myself speak Australian English, but in certain contexts (especially talking about computers, or at work – I work for a US-based company) I tend to Americanise my English a little bit. Australian English is neither American nor British – it tends to be closer to British mostly (e.g. petrol not gasoline), but sometimes is closer to American instead (e.g. truck not lorry), and sometimes does its own thing–e.g. Americans say bell peppers and the British say sweet peppers but Australians for some reason use the Latin name capsicum (for the mild ones, not the spicy ones) – which is not unique to Australia, New Zealand and Indian English do that too.
Anyway, we don't need to tag documents with the precise dialect of English. We all understand each other pretty well anyway.
Also, locale != language. Locale is about stuff like date formats, number formats, etc. It is rare for a non-interactive website – as opposed to an interactive webapp - to support multiple locales.
> Also, locale != language. Locale is about stuff like date formats, number formats, etc. It is rare for a non-interactive website – as opposed to an interactive webapp - to support multiple locales.
I know. But ideally you’d still be conforming to some sort of locale for each of your chosen languages.
Even static text can refer to dates. And while ISO 8601 really is the proper unambiguous way to refer to all-numeric dates we still have the British and most of rest of the world preferred way of day-month-year, whereas with American English the preferred way is month-day-year.
And likewise, if you are writing for an Australian audience then the assumed currency when you say naked “dollars” will be AUD. Whereas text for Canadian audiences will have CAD being the assumed meaning of naked “dollars”.
And that’s why I mean that there often is a locale tied even to text. But you are absolutely right that it is complicated, and that often smaller sites will be written with a global audience in mind and no clear locale. But then the rule still applies. And since you are then not using en_US nor en_GB etc, but just plain en, there is no flag for that and you’d represent it with text saying just “English”.
I know. But ideally you’d still be conforming to some sort of locale for each of your chosen languages.
Even static text can refer to dates. And while ISO 8601 really is the proper unambiguous way to refer to all-numeric dates we still have the British and most of rest of the world preferred way of day-month-year, whereas with American English the preferred way is month-day-year.
And likewise, if you are writing for an Australian audience then the assumed currency when you say naked “dollars” will be AUD. Whereas text for Canadian audiences will have CAD being the assumed meaning of naked “dollars”.
And that’s why I mean that there often is a locale tied even to text. But you are absolutely right that it is complicated, and that often smaller sites will be written with a global audience in mind and no clear locale. But then the rule still applies. And since you are then not using en_US nor en_GB etc, but just plain en, there is no flag for that and you’d represent it with text saying just “English”.
> Even static text can refer to dates. And while ISO 8601 really is the proper unambiguous way to refer to all-numeric dates we still have the British and most of rest of the world preferred way of day-month-year, whereas with American English the preferred way is month-day-year.
It is really only an issue for all numeric dates. If you put the month in words, everyone gets it regardless of the order. Everyone understands that ''4 July'' and ''July 4'' (or ''July 4th'') are the same thing. In fact, in British (and Australian) English, at least, both ways are strictly speaking correct. Month-first is viewed as somewhat old-fashioned but still encountered especially in some very formal contexts. (Actually, a lot of American-British differences are due to American English being more conservative, and failing to adopt changes in the language which later occurred in England, and the differences in date order are an example of that)
> And likewise, if you are writing for an Australian audience then the assumed currency when you say naked “dollars” will be AUD. Whereas text for Canadian audiences will have CAD being the assumed meaning of naked “dollars”.
As an Australian I have no trouble working out what "dollars" means based on context. I will assume it means US dollars unless I am reading an Australian website (or Canadian or New Zealand or so on). Formally tagging the website with a locale is pointless for this. Anyway, one can always be explicit (USD vs AUD or US$ vs AU$), and in my experience a lot of texts are. Explicitness is always the best when dealing with international audiences. And, commonly, Australian news sources will, when reporting international news, give the foreign amount first (USD or EUR or GBP or JPY or whatever) and then an Australian dollar conversion in brackets. (I expect Canadian and New Zealand news sources would do the same thing.)
> And that’s why I mean that there often is a locale tied even to text.
Often, when talking about texts, house style is a more important concept than locale. For example, the United Nations (and its agencies) has its own rules about spelling English words, they mostly follow American conventions (e.g ''World Health Organization'' not ''World Health Organisation'') but sometimes use British spellings instead (e.g ''United Nations Environment Programme'' not ''United Nations Environment Program''). I don't know if you can easily map an organisation's house styles to locales.
The other problem is what is in a locale is often disputed. For example, what is the first day of the week in Australian locale, Sunday or Monday? There is actually no consensus on this question in Australian culture. My wife and I can't agree on it, and even Australian media reflects the lack of consensus [0]. However, interestingly, while the ABC (our national public broadcaster) says the official answer is Monday, Unicode CLDR says Sunday, and most software vendors have followed Unicode. But, Unicode CLDR actually used to say Monday, and someone talked Unicode into changing it. Maybe I should try to talk them into changing it back :)
[0] https://www.abc.net.au/news/2019-08-18/which-day-do-you-cons...
It is really only an issue for all numeric dates. If you put the month in words, everyone gets it regardless of the order. Everyone understands that ''4 July'' and ''July 4'' (or ''July 4th'') are the same thing. In fact, in British (and Australian) English, at least, both ways are strictly speaking correct. Month-first is viewed as somewhat old-fashioned but still encountered especially in some very formal contexts. (Actually, a lot of American-British differences are due to American English being more conservative, and failing to adopt changes in the language which later occurred in England, and the differences in date order are an example of that)
> And likewise, if you are writing for an Australian audience then the assumed currency when you say naked “dollars” will be AUD. Whereas text for Canadian audiences will have CAD being the assumed meaning of naked “dollars”.
As an Australian I have no trouble working out what "dollars" means based on context. I will assume it means US dollars unless I am reading an Australian website (or Canadian or New Zealand or so on). Formally tagging the website with a locale is pointless for this. Anyway, one can always be explicit (USD vs AUD or US$ vs AU$), and in my experience a lot of texts are. Explicitness is always the best when dealing with international audiences. And, commonly, Australian news sources will, when reporting international news, give the foreign amount first (USD or EUR or GBP or JPY or whatever) and then an Australian dollar conversion in brackets. (I expect Canadian and New Zealand news sources would do the same thing.)
> And that’s why I mean that there often is a locale tied even to text.
Often, when talking about texts, house style is a more important concept than locale. For example, the United Nations (and its agencies) has its own rules about spelling English words, they mostly follow American conventions (e.g ''World Health Organization'' not ''World Health Organisation'') but sometimes use British spellings instead (e.g ''United Nations Environment Programme'' not ''United Nations Environment Program''). I don't know if you can easily map an organisation's house styles to locales.
The other problem is what is in a locale is often disputed. For example, what is the first day of the week in Australian locale, Sunday or Monday? There is actually no consensus on this question in Australian culture. My wife and I can't agree on it, and even Australian media reflects the lack of consensus [0]. However, interestingly, while the ABC (our national public broadcaster) says the official answer is Monday, Unicode CLDR says Sunday, and most software vendors have followed Unicode. But, Unicode CLDR actually used to say Monday, and someone talked Unicode into changing it. Maybe I should try to talk them into changing it back :)
[0] https://www.abc.net.au/news/2019-08-18/which-day-do-you-cons...
> Maybe I should try to talk them into changing it back :)
As an Aussie, I'd love to help you with that haha. Unicode is wrong ;)
As an Aussie, I'd love to help you with that haha. Unicode is wrong ;)
https://unicode-org.atlassian.net/browse/CLDR-14795 is the issue.
Maybe it would help convince them if more Australians endorsed the "Monday is first day of week in Australia" position.
On the other hand, I don't want to overwhelm the poor Unicode CLDR developers with too many "me too" comments.
Maybe it would help convince them if more Australians endorsed the "Monday is first day of week in Australia" position.
On the other hand, I don't want to overwhelm the poor Unicode CLDR developers with too many "me too" comments.
I'm super impressed by the progress so far! I didn't end up writing my comment of support as it seems like they're amenable to the change based on the work you put in: well done!
Why not? It seems perfectly intelligible to me which flag means what language.
To you, yes - but how would a Taiwanese or PRC person feel if their opposing flags were used to represent their language? (Or me, as a Brit, seeing the US Flag to represent English...)
Yes, it's true that languages tend to be country-specific (e.g. en-US: USA, en-GB: UK, pt-BR for Brazilian Portuguese, etc), but while that's technically true, the majority of Indo-European languages that have spread widely across many nations, don't have enough differences between them to justify using a single specific country flag to represent all of them (namely, en-GB, en-CA, en-AU, and en-US, they're hardly even separate dialects).
In short: Flags identify countries, not languages.
By analogy, it's like using the Java language logo to represent all Java-derived languages (C#, Swift, Golang, Kotlin) because they're mutually-intelligible.
Yes, it's true that languages tend to be country-specific (e.g. en-US: USA, en-GB: UK, pt-BR for Brazilian Portuguese, etc), but while that's technically true, the majority of Indo-European languages that have spread widely across many nations, don't have enough differences between them to justify using a single specific country flag to represent all of them (namely, en-GB, en-CA, en-AU, and en-US, they're hardly even separate dialects).
In short: Flags identify countries, not languages.
By analogy, it's like using the Java language logo to represent all Java-derived languages (C#, Swift, Golang, Kotlin) because they're mutually-intelligible.
> ... Java-derived languages (C#, Swift, Golang, Kotlin) ...
Swift and Go do not belong to that list.
Swift and Go do not belong to that list.
The home page is a very good read : https://www.purebasic.fr/blog/