Like all those old furniture or door locks that I just assumed were lost causes, many locksmiths can actually make keys for them. Not usually a serious need for it but if you were selling an old piece of furniture you might do it. In my case we have a bedroom closet we'd like to lock some stuff away in when we go away and have someone come in to feed the animals.
The ability to make a key for locks which have no key is another, even if those locks don't have removable cores (I'm thinking of mostly padlocks here). That's a really cool thing called impressioning, where the mechanics of the lock (pins pressed down into the keyway by springs) are actually used against it to progressively turn a key blank into a working key.
Master keying is another great example (when multiple, different keys work in a lock and you can have one key that works in multiple locks, such as a small apartment building).
Also a lot of ancillary things around the lock but not the lock itself, for example installing deep screws or replacement anti-kick hinges (door devil or door armor). In theory those are DIY things but in practice you can spend a lot of time trying to get alignment right (especially with a deadbolt going smoothing in/out), but it's something a locksmith does all the time.
Sometimes they can even make a key by sight reading, peering down the keyway; this is especially common (for good locksmiths) with wafer locks (often seen on cabinets, and autos but those are usually too complex to sight read).
The downside is that it is a very common marketing trick. Promise something so that customers feel good about it.
I know the Rust contributors are doing their best, and that this blog post is not writing a marketing ploy, but in the end, the result is what matters.
My take on this is that I am fine with compile times as long as some effort is being done to keep it near optimal.
But I really do not want the Rust team to feel pressure to improve the compile times so much that they will end up killing other features or designing the language differently just for that (like Go, for instance). Or even making the compiler so complex that adding new features is harder for them.
I really like Rust as a language that is more complex to write and to compile but in return gives you robustness and performance. Compilation times be damned. I am not writing Rust to compile fast!
I want two different languages. I want one that compiles fast so I can run my unit tests fast. I want one that takes however long needed to get the fastest binary. These need not share the same compiler so long as both compile the same source to the same result.
> I want one that takes however long needed to get the fastest binary.
Year after year, people keep saying this or things like it. But it's worth remembering that it is not the compiler that makes your code fast, but how you structure your data transformations that makes code fast. In 2014, Mike Acton taught us that the best compiler optimisations can only account for 1-10% of the performance optimisation problem space. "The vast majority of [performance] problems, are problems the compiler cannot reason about." https://youtu.be/rX0ItVEVjHc?t=2097
Is that really true in all cases though? That's certainly true for languages like c++ and C and other compiles languages with manual memory management because the compiler can't re-order things past a memory load. That's less true I think for languages like where Rust can get to (even if they're not there yet). In Rust you can reason about memory allocations because there's guaranteed invariants in safe rust that let the compiler reason more about what the code is doing and rearrange instructions more than what would be possible in C or C++.
> [...] because the compiler can't re-order things past a memory load.
Re-ordering of reads and writes is not really the problem either, even if we assume that one could automatically safely reorder reads and writes arbitrarily to yield significant optimisations. Fundamentally, the compiler does not know the semantics of your data and the relationships between pieces of data and the logic of their transformations. Knowledge of your specific problem and the specific data you are transforming yields the majority of the powerful optimisation opportunities. Similarly, a garbage collector doesn't know the meaning of your data or your algorithms.
> Is that really true in all cases though?
Consider: Given a set of data, if a compiler or garbage collector understood the data sufficiently, then there would be no need for you to exist to write the program, because the compiler could simply write the data transformations itself and generate the program.
However, one is encouraged to do experiments for oneself. Concrete profiling data, not abstract theory, is what matters when evaluating cost-benefit of any approach.
>The downside is that it is a very common marketing trick.
"The less you intend to do about something, the more you have to talk about it." However this maxim is not applicable here because compile times actually have been improving.
This. Don't ever dumb down a language just to make tools faster. Anything the tools don't help with, I have to do with my brain, which is made of meat and runs at 0.0000001 GHz.
There is definitely a marketing angle to these posts. Rust has a reputation for slow compilation, and one of my goals is to show that (a) people working on Rust care about compile times, and (b) improvements are being made.
I'll let you judge whether the marketing is backed by actual substance. It's a long-running blog post series, here are links to all the posts.
Learning up to C++20 if you are an experienced C++ programmer is easy as long as you only use whatever features you learn or make sense for your project.
Studying everything new is, of course, a much more ambitious goal.
Agreed, it is lacking tooling support and many other things, but it is a cleaner C++. That plus the borrow checker are its two major features. Otherwise, nobody would use it and their designers would have done a pretty bad job given the 30 years of experience they had from C++!
Advisors are also very much at fault, not just students.
The last year of my PhD I ended up being pretty much alone because my advisor had changed research topics a year before and therefore was not interested nor up to date, so any of her inputs were not very useful.
A couple friends of mine also struggled with their advisor because he actively avoided communication for some reason. I guess he had a personal or health issue.
So even on good faith, advisors can end up making students life quite stressful for one reason or another
- Almost no one does accessibility properly in web apps. Even native apps get it wrong more often than not.
- Using Electron does not give you accessibility in any way.
- What laws? I use everyday general purpose commercial applications, both webapps and native apps, with glaring accessibility flaws and I do not see anybody caring to sue.
- I don't know of any business doing general purpose commercial applications that has faced any issues with that.
> - Almost no one does accessibility properly in web apps.
Screen readers can still (badly) work on web sites that haven't been made with accessibility in mind. And if you find you need to add proper accessibility to a web or native app, you can. With something like godot, you might have to rewrite the entire GUI to get accessibility working properly.
> - Using Electron does not give you accessibility in any way.
Yes it does. Electron gives you basic out-of-the-box crossplatform support for accessibility, just like chrome. And you can tweak the screen reader output the same way you would a website. See: https://www.electronjs.org/docs/tutorial/accessibility
> - What laws?
EU: According to the first google result, by September 23 2020 all websites and mobile apps must be accessible to everyone, have a public accessibility policy, provide a feedback mechanism for users to report inaccessible content and provide a link to the enforcement procedure:
> - I don't know of any business doing general purpose commercial applications that has faced any issues with that.
You don't know anyone who's faced issues yet. Momentum behind these laws is growing in most countries, bolstered by the 2008 UN Convention on the Rights of Persons with Disabilities - which requires countries to "Provide information in accessible formats and technologies appropriate to different kinds of disabilities in a timely manner and without additional cost". In the US and Canada the law currently only requires government websites to be accessible, but its not a safe bet to assume things will stay like that.
The screen reader is not supported or useless on most web apps.
Again, we are talking apps and their GUI (web and native), not sites or documents.
> With something like godot, you might have to rewrite the entire GUI
Again a "might". I don't see any reason why you need any "rewrite".
> laws
Those are not for general purpose commercial apps as I wrote, only for public or specialized apps.
> You don't know anyone who's faced issues yet.
So then it is fear mongering, aka FUD.
> Provide information in accessible formats and technologies
Information, not GUI on apps.
Public information, at that.
It is simply impossible to require at the moment accessibility for web apps or native apps.
It does not even make sense for a huge amount of software. For example, an image editor or the vast majority of games cannot be accessible for a blind person with current technology.
Accessibility is critical on information and documents, not on common apps. That is why things like websites using fancy web frameworks just to display text is bad because they tend to break it. Nobody is discussing that, you are conflating apps with documents.
If you've made a "web app", it must be accessible through the web, i.e. it is either a web site or a part of web site, according to all sorts of laws including probably the ones mentioned by the GP post.
Forget about the fear-mongering - think about the actual people with disabilities though.
If you're in the public sector, or have customers in the EU or Australia, you might get sued or fined if your app isn't accessible.
Weirdly even in the US you might not be in the clear for internal tooling. My understanding is its illegal to refuse to hire a blind person because they're blind. If you hire someone who's blind and they can't do their job because your internal tools are written in Godot, you might be leaving yourself open to discrimination suits. Not a big deal when you're a startup, but it will matter at google / fb / etc. I'm sure google has blind employees today who care a great deal about being able to do their jobs.
That sounds like a legal minefield, with more mines added over time.
In short, if you aren't making a video game or a toy, it seems like good advice to use tools that work with accessibility.
1. There is no law on the horizon that will require any accessibility for general purpose commercial apps.
2. Further, one can add accessibility features on Godot or other engines if needed. No technical limitation whatsoever.
3. If such laws came to be in a decade or two, engines and frameworks of all kinds will most likely support those features on their own.
4. The only case you can make against Godot is that someone has a company which hires people; and finds a blind person that is as productive as a non-blind to the point they are the best candidate for the job; and the company is in a country with such laws; and someone is an asshole that does not want to hire such person even if they are the best; and the position requires to use Godot tools; and the tools are non-accessible to begin with; and that someone does not want to spend the money to make them accesible; and the rejected candidate sues you and wins the case.
No business will even think about such an scenario. In an ideal world, they would. In the real world, they don't. And I am siding with the blind person in such a case and hoping such a company is busted in that case. But the case is extremely rare.
So, as a busines risk, for a commercial startup, this is pretty negligable, right?
Even if they widen the scope, EU commercial laws on this kind of thing (e.g. content filters) tend to be only applied to companies over a certain revenue level (10m euros for the content filters).
Also, EU regulation is enforced differently to US regulation. EU regulators tend to ask nicely the first time, and only impose fines if it's a repeat offence, or the company has flat-out refused to do anything about the problem.
In other words, even if the regulation scope is widened, anyone building their GUI with Godot will probably have enough revenue and be given enough time to rebuild it completely before they'll reach the point of "business-killing" fines.
<of course, being accessible is a good thing in its own right, and I'm glad Godot appear to be doing something about it>
> They are not applicable to websites or applications built in the private sector.
The Americans with Disabilities Act, however, is applicable to private businesses; though (unless things have changed recently) there is currently an unresolved three-way split in federal circuits about high it applies to website with the Third Circuit saying it doesn’t, the First, Second, and Seventh Circuits saying it does generally, and the Sixth, Ninth, and Eleventh Circuits splitting the difference and saying it does if their is sufficient nexus between the website and a physical location of business, and the California State Courts seem to (in applying the state Unruh Civil Rights Act, which includes among it's triggers ADA violations) holding that it is at least applicable in the nexus case.
> For example games have exactly zero accessibility support, system actually knowing about what is being rendered is quite useful for it to provide tools like voice over.
Some engines do have accessibility support. Most games don't do accessibility because it costs money. Same as web apps, by the way. It is not a technical limitation.
> What about IME?
What about it? It works just fine in any proper engine. There are a lot of non-Latin-charset speakers in the world...
