[dead]
Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
11–20 of 27 posts
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#12Earlier quoted context omitted.
If they have a trademark they don't defend, they can lose it.
The word "micron" is a common unit of measurement (μm). The trademark Micron™ only applies to microelectronic hardware, I suppose.
They also have a Micron trademark for software, as they sell some software packages. So it's really just a question of whether or not they notice and decide to go after you.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#13Micron seems like a bad naming choice...maybe it predates the manufacturer?
«The term micron and the symbol μ were officially accepted for use in isolation to denote the micrometre in 1879, but officially revoked by the International System of Units (SI) in 1967.»
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#14Earlier quoted context omitted.
They surely have better things to do than worry about what I call my programming language.
If they have a trademark they don't defend, they can lose it.
No. This is a common misconception. I know, you asked an LLM and it said you were very right and it cited a bunch of legal cases which prove you correct. You didn't check any of those citations, because they looked right, because it's an LLM and generating plausible nonsense is exactly what it's good at.
Or worse, you just relied on a vague memory that other people said the reason they have to do something reprehensible was because it's legally required, and even though you've heard that bullshit from a dozen US politicians in the last week and know it's bullshit you thought they must be correct.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#15I'd be more interested in the results, relative to the languages from the main repository.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#16Earlier quoted context omitted.
If they have a trademark they don't defend, they can lose it.
No. This is a common misconception. I know, you asked an LLM and it said you were very right and it cited a bunch of legal cases which prove you correct. You didn't check any of those citations, because they looked right, because it's an LLM and generating plausible nonsense is exactly what it's good at. Or worse, you just relied on a vague memory that other people said the reason they have to do something reprehensi…
No, I've been interested in "intellectual property" restrictions since last millennium, so I've been familiar with the outlines of US trademark law for a while. You evidently are not. Aside from the reductions in scope resulting from laches and equitable estoppel, demonstrating a clear record of enforcement efforts is crucial to preventing genericization, which can befall even the most inherently distinctive marks such as "heroin".
Nowadays it can indeed be difficult to avoid getting taken in by LLM bullshit even if you don't ask an LLM yourself, but it is still possible.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#17I'd like to hear more about the Oberon languages and compilers used.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#18I'd be more interested in the results, relative to the languages from the main repository.
There are some results in the repository, e.g. one I published recently: https://github.com/rochus-keller/Are-we-fast-yet/blob/main/L...
Or here: https://github.com/rochus-keller/Oberon/blob/master/testcase...
The main repository only recently added a C++ implementation, but it was significantly slower than mine when I check last time (see https://github.com/smarr/are-we-fast-yet/issues/80).
I mostly use the benchmarks to check how my compilers do compared to the big ones, or how the technologies I'm interested in evolve.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#19I'd like to hear more about the Oberon languages and compilers used.
Re: Are-we-fast-yet implementations in Oberon, C++, C, Pascal, Micron and Luon
#20I'd be more interested in the results, relative to the languages from the main repository.
The original repo is about using a subset of a language to compare language implementations. I can see the point in that. But language benchmarks like this are incredibly useless and very easy to get wrong anyway. For example it you actually cared about performance for the bounce example you would never write it like this in C. Bouncing 100 balls in a loop 50 times with 4 ifs just tests the branch predictor. There is nothing to learn from this in practice.