PureBasic switches to a C backend
purebasic.fr
purebasic.fr
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'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/
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).
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.
it works.
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.
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...
https://github.com/harbour/core#supported-platforms-and-c-co...
You must be speaking of the demo version.
Gambas is a mature, current-generation OO BASIC, has a vast array of libraries, a JIT and is completely open source software.
--
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.
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.
Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
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.
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.
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.
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.
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.
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#.
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)
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.
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.
What do you use it for?
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.
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.
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.
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
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.
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 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.
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.
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.
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
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.
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.
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”.
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...
As an Aussie, I'd love to help you with that haha. Unicode is wrong ;)
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.
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.
Swift and Go do not belong to that list.