But one can only use Qt from C++?
...and 16 other languages.
But one can only use Qt from C++?
...and 16 other languages.
Python isn't a bad first language. It has all the important advanced concepts - objects, dictionaries, closures, and threads. The syntax is reasonable. Some people are bothered by the forced indentation, but for new programmers, it will seem natural.
I would argue that the main issue is Python's lack of static typing. Pretty much every non-interpreted language has static typing, and it's arguably more fundamental/basic than OOP.
And the problem is?
The experts developed those rules over time - an expert system is incapable of that sort of learning. If anything changes, they won't have anyone who understands the basis of the system well enough to define new rules.
You can't tell people how to feel - how often does telling an angry person to calm down work?
I have some personal experience in this, and the trick seems to be to break the cycle. You're depressed because your situation sucks, and your situation sucks because you're depressed. Working at overcoming the symptoms of depression is a rational solution because it breaks the loop, but it's not an emotional one because they still feel like crap (at least until things pick up, but even then there'll be depressive bouts). Wording things such that you're not invalidating them will make them more receptive, but it is very much a case of having to walk uphill to get treatment for a broken leg.
That said, the person in question actually has to learn how to break that cycle; it's not something you can just tell them. There are things like CBT that are based around this, but at the end of the day it's very much based around learning how to regulate and control your emotions.
I disagree - Perl's biggest issue is that things which should be defined in the language's grammar are instead defined in code. This reduces it to a language of special cases.
Consider the following:
$_ = foo 1;
Does the function bar, in the absence of an argument, use $_ as its argument?
Some functions do, some don't, and this is true even among the core functions. This is because the implementer of the function must explicitly read from the global $_, rather than the language passing the argument to it. The resulting inconsistency can make it difficult to reason about what a Perl script is actually doing.
There are other issues, such as variables inside functions being global by default, but that's the big one.
I suggest you look at using D instead. It is as powerful and efficient as C++, syntactically very similar to C#, and can link C++ libraries.
The main benefit this provides (apart from performance) is that it will be much easier to do a cross-platform release - although C# has Mono, I've found it to be unreliable.
That said, D is somewhat obscure, so caveat emptor.
tldr: good faith = don't be a dick
Disclaimer: IANAL, and I am not particularly familiar with equity law, which (promissory) estoppel falls under.
In contract law, acting in bad faith refers to following the literal wording of the contract while taking actions that would deprive the other party of their benefits. e.g. you lease a car, but do not provide the car key. In some jurisdictions there is an implied duty of good faith in contracts, while in others explicit terms are required.
Now, in this case there is no contract because there is no quid pro quo relationship between Tesla and the licensees (the legal term is consideration). Instead it is enforceable by promissory estoppel, which essentially means Tesla can't sue someone who relied on their statements.
Since Tesla isn't explicitly receiving anything in return for the license, it's unclear what an action in bad faith could deprive them of.
One argument would be that the benefit Tesla accrues from this is that other companies will (hopefully) build infrastructure. It's entirely possible that they may choose to do so using Tesla's patents but with incompatible, DRM'd connectors. I suspect this is what the good faith requirement is intended to prevent. (Non-DRM'd connectors would be more of a grey area, since they could argue that it was used simply because their technology is better.) In other words, the other company would not be permitted to prevent Tesla from supporting their charging stations if they used the patents in question.
You see, if you don't have license terms spelled out, this whole thing is subjective, and you'd be stupid to use their patents.
Subjectivity cannot be eliminated completely; that is why the reasonable person test is used in law. Most (or possibly all) human languages require some interpretation on the part of the reader, and as a result terms like 'reasonable person' and 'good faith' are used in law to imply that such interpretation is required there.
Clearly we just need a small set of POSIX apps to do 'git, 'make' and 'gcc' on your phone.
Download the signed source code from the app store.
You jest, but given that ChromeOS is a Gentoo-derivative, it might not be that far off...
I'll second this. I got a paid subscription to them after the picked up a kernel performance regression bug that no one else had noticed. They also regularly do file system benchmarks, which are really useful if you're interested in that.
C# is now 14 years old - I highly doubt it can be considered fly-by-night at this point. Not to mention Swift doesn't even achieve feature parity with it - it lacks C#'s variant generics and list comprehensions (which seem to be combined with lazy evaluation and called LINQ in C#).
My underlying point is, why create a new language? It's justifiable if you're actually trying to add new features or paradigms (e.g. Rust was created so that memory safety could be enforced at compile-time), but otherwise it's just change for the sake of change. It would make more sense to adopt the syntax of an existing language (e.g. Java, C#, C++, etc.) so as to leverage existing users of those languages, rather than requiring them to relearn the semantics. If you need to replace Objective-C, why create a whole new language when there are plenty of perfectly good ones already?
Quite frankly, it looks like a poor man's C#, with some Haskellisms (tuples, -> syntax) thrown in for good measure. I'm sure it's better than Objective C, but it's nowhere near competitive with any of the other recent languages. e.g. Rust*
* I think Rust is a long way from perfect and has a myopic focus on low-level coding where manual memory management matters, but at least they're doing something interesting.
KDE worked fine on 32-bit ARM, last I checked. If they're going through the effort to support a completely different architecture, I'm pretty sure they'll still support 32-bit x86.
Also, I'm not sure that PAE-support should even make a difference to anything running in userspace...
That's great, if you're only using KDE apps. What about apps that are neither KDE/Qt or Gnome? VLC is the first that comes to mind. xmms2 is another. Or, what if I want to use WinAmp through Wine? All of this just works in MATE/Gnome/Cinnamon with gvfs.
The media playing apps should be file system agnostic -- they shouldn't have to know about URLs or network protocols.
I just tested this with FTP and Audacity, and the files are copied to temporary directories before being opened in non-KDE apps. (Actually, they're copied for both, but to different directories for some reason...)
I'm using Sabayon with KDE 4.13.0 - you're either using an older, buggy version, or there's something wrong with your setup.
I'm not sure about Plasma-next, but I could comfortably run KDE 4.10 (or thereabouts) on a tiny little Tegra 2 clocked at 1 GHz with 1 GB of RAM and no hardware acceleration. Chrome ate more RAM than KDE ever did. I've also used KDE quite comfortable on a Pentium 4.
So if KDE doesn't run on your desktop, then I'll wager one of the following is the case:
-you have horribly broken graphics drivers. Try changing the compositing mode, graphic driver, etc.
-your PC is over a decade old
-you have stumbled across an extremely rare and specific bug in KDE
This universe shipped by weight, not by volume. Some expansion of the contents may have occurred during shipment.