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.
Re:There's nothing wrong with Perl ...
on
Perl Is Undead
·
· Score: 1
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; bar; print;
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.
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.
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
And with baloo replacing nepomuk, email search finally works - far faster than kmail1 ever was, I have over a 100,000 msgs which it can full text search in seconds.
If you're using 4.13.0 (the first version with baloo), or about to upgrade, here are two things I learnt the hard way:
When KNotes asks if you want to migrate your notes, say no. The migration process wipes them, and recovering them is non-trivial.
If you have any virtual machines, make sure you've got limits.conf set to prevent baloo from eating all your RAM
Such is life on the bleeding edge... But apart from that, Kmail/Kontact works great for me (especially with Kolab).
And yes, all machines - including cars - should have a kill switch that mechanically cuts off the power. Industrial machines are required to have those, so why should land missiles mostly operated by amateurs be exempt?
Most industrial machines are electrical; the kill switch is just a switch. Implementing something similar for an IC engine is probably considerably more complex.
If I know Tony Abbot and co, there are government law drafters who have been given the task of taking the UK RIP act (the one that lets them send you to jail for refusing to hand over encryption keys) and invent a similar law that fits the Australian system.
It sounds more like an approximation. Given a failure rate of p and 2 (non-redundant) engines, the probability of system failure is 1 - (1 - p)^2 = 2*p - p^2. p > p^2, which means we can neglect the squared term, leaving just 2p. It's not the sort of thing you'd do in a rigorous analysis without formally stating the justification, but it's exactly what I'd expect from a back of the envelope approximation or an informal explanation. Someone with a strong background in probability would probably do this sort of approximation almost subconciously.
But the program performs functionally the same. That's the rule followed when doing compiler optimisations.
memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.
The program will generate the same output yes, but the security implications are not the same. This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.
Zeroing memory like this is a common practice in such cases.
You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.
This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.
Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.
If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?
The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.
See, that's the thing. You got used to changing your fonts around because in the old days fonts sucked. We didn't really have a good font system. All the other non-free desktops had a great font rendering system. Now we have something decent, you shouldn't have to screw around with fonts. It should just work. That's why GNOME doesn't have that many options for fonts. Neither does OSX nor Windows. You can still do the same kind of font fiddling before, you just have to use gsettings or tweak tool to do it. But they exist, but we need to build something greater. What we're doing is much harder, making things work for the general case.
People change fonts when the defaults don't suit them, and there is no one choice that will suit everyone. The logical conclusion of this is that you need to have some method by which people can change the setting, or your software will not be suitable for a significant number of people.
Sane defaults do not remove the need for configuration. Look at KDE - their defaults are perfectly fine for most people, but Plasma is/way/ more configurable than Gnome 3. This one-size-fits-all attitude is the primary reason people have responded poorly to Gnome 3.
GNOME offends people who use computers as a creative extension of themselves.... I used to be one of those people, but life is too short, I prefer to take what I am given and work on the things that really matter to me.
False dichotomy much? Changing the font size should be a trivial task doable in under 5 minutes (including the time taken to Google it). Furthermore, has it not occurred to you that people who use computers as extensions of themselves are actually the majority of Linux users? Minor changes that make our tools easier or more efficient to use are the norm for us. If we weren't interested in changing our tools, we wouldn't have installed Linux in the first place. It's all well and good to target other demographics, but if you alienate your userbase and focus on a minority, then it should hardly be surprising when your users (and their funding) disappear.
It definitely comes from an older era where you can spend hours tweaking conf files.
I disagree. Spending hours tweaking conf files was the norm back in the 90s out of necessity, but the idea of customizing your tools to suit yourself is not specific to that era. I'm young enough to not remember most of the 90s and have used Linux for less than a decade, but I often spend time customizing my setup to suit myself better.
If they were using a custom malloc, then they should have been memset (or similar) to zero the blocks when debugging. That way, use-after-frees still manifest as crashes when testing (it could be disabled in release builds to improve performance). I'm in no way an experienced C programmer, but if I were reimplementing something as core as malloc/free I would include a ton of sanity checks and safeguards to make sure that, at least on debug builds, this sort of bug was obvious.
But wanting a GC has nothing to do with "brain dead idiots". It has been established decades ago that manual memory management is simply prone to errors, as program size increases. That includes expert programmers. This is a settled empirical question. If the overhead is acceptable, there is little reason to not want a GC.
There is also a third option: manual memory management with compile-time guarantees of safety. You get the performance of manual memory management without the risks, and the code ends up being more concise because heap allocation is implemented as a syntax feature. Rust is the most well known example of this.
Then again, you could just pick full C++ 11, which has the advantages of both the higher level of abstractions like C#, and the low level capabilities of C.
Speaking as someone who has worked with both C++11 and C#, C# is a much nicer language. C++11 improves things somewhat, but it's an old language and the cruft shows. The obvious example is generics: C#'s generics are quite straightforward to use, support constraints (base classes of type parameters), and can even be annotated to handle inheritance correctly. C++'s templates are notorious for their poor usability, to the extent that even Stroustrup recognizes that they fall short. A future version of C++ is supposed to implement Concepts, which provide the ability to add arbitrary constraints to type parameters (but not by using inheritance*, for some reason.)
It's quite telling that even though I've been using Linux as my primary OS for a few years now, I still haven't found a language that's as pleasant to use on it as C# was under Windows. (Qt is much nicer than the.NET Framework though.)
*To be fair, inheritance has the problem that once a class is written, you can no longer add base classes to it. But this is not insurpassable; C# supports extension methods that could be used to fix this in a manner similar to Haskell's type classes.
I avoided bluetooth for years becuase it was unreliable and awkward. The headsets were expensive and uncomfortable. Some didn't work in that they required pairing every time you turned it on. (Both the phone and the device completely forgot about each other.) Buying a corded headset was far cheaper, had far better quality, and was far more comfortable.
But times change, as do needs. Most bluetooth devices now have just enough non-volatile memory to remember what they were last paired with and most bluetooth hosts will quite happily keep a list of every device it's ever pair with. Other than the initial setup (which can still be awkward and annoying) it's quite simple to use now. Hold the button for a few seconds until the light blinks and/or the sound chimes. Now I have a whole host of bluetooth devices.
It's funny you mention this, given that just a few days ago I struggled and eventually gave up on getting my laptop to pair with a Bluetooth ODB adapter that had previously paired with a different laptop. (In the end I gave up, took it apart, and soldered some wires directly to the serial interface inside it, as I had a USB UART adapter on hand).
The problem was that the device kept disconnecting after I connected to it, and there was nothing I could do to convince it otherwise. The more complex a technology is, the harder it is to get the interface right. This goes doubly when you have an embedded system without a second, more powerful interface (compare this to how Linux supplements the GUI with a terminal). Wearable devices take this to an extreme; the interface is more limited than that of a phone, so it's even harder to get right.
Slashdot Mirror
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:
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
And with baloo replacing nepomuk, email search finally works - far faster than kmail1 ever was, I have over a 100,000 msgs which it can full text search in seconds.
If you're using 4.13.0 (the first version with baloo), or about to upgrade, here are two things I learnt the hard way:
Such is life on the bleeding edge...
But apart from that, Kmail/Kontact works great for me (especially with Kolab).
And yes, all machines - including cars - should have a kill switch that mechanically cuts off the power. Industrial machines are required to have those, so why should land missiles mostly operated by amateurs be exempt?
Most industrial machines are electrical; the kill switch is just a switch. Implementing something similar for an IC engine is probably considerably more complex.
If I know Tony Abbot and co, there are government law drafters who have been given the task of taking the UK RIP act (the one that lets them send you to jail for refusing to hand over encryption keys) and invent a similar law that fits the Australian system.
They'd be a bit late.
-- http://en.wikipedia.org/wiki/K...
It sounds more like an approximation. Given a failure rate of p and 2 (non-redundant) engines, the probability of system failure is 1 - (1 - p)^2 = 2*p - p^2. p > p^2, which means we can neglect the squared term, leaving just 2p.
It's not the sort of thing you'd do in a rigorous analysis without formally stating the justification, but it's exactly what I'd expect from a back of the envelope approximation or an informal explanation. Someone with a strong background in probability would probably do this sort of approximation almost subconciously.
But the program performs functionally the same.
That's the rule followed when doing compiler optimisations.
memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.
The program will generate the same output yes, but the security implications are not the same.
This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.
Zeroing memory like this is a common practice in such cases.
You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.
This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.
Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.
If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?
The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.
See, that's the thing. You got used to changing your fonts around because in the old days fonts sucked. We didn't really have a good font system. All the other non-free desktops had a great font rendering system. Now we have something decent, you shouldn't have to screw around with fonts. It should just work. That's why GNOME doesn't have that many options for fonts. Neither does OSX nor Windows. You can still do the same kind of font fiddling before, you just have to use gsettings or tweak tool to do it. But they exist, but we need to build something greater. What we're doing is much harder, making things work for the general case.
People change fonts when the defaults don't suit them, and there is no one choice that will suit everyone. The logical conclusion of this is that you need to have some method by which people can change the setting, or your software will not be suitable for a significant number of people.
Sane defaults do not remove the need for configuration. Look at KDE - their defaults are perfectly fine for most people, but Plasma is /way/ more configurable than Gnome 3. This one-size-fits-all attitude is the primary reason people have responded poorly to Gnome 3.
GNOME offends people who use computers as a creative extension of themselves. ... I used to be one of those people, but life is too short, I prefer to take what I am given and work on the things that really matter to me.
False dichotomy much? Changing the font size should be a trivial task doable in under 5 minutes (including the time taken to Google it).
Furthermore, has it not occurred to you that people who use computers as extensions of themselves are actually the majority of Linux users? Minor changes that make our tools easier or more efficient to use are the norm for us. If we weren't interested in changing our tools, we wouldn't have installed Linux in the first place.
It's all well and good to target other demographics, but if you alienate your userbase and focus on a minority, then it should hardly be surprising when your users (and their funding) disappear.
It definitely comes from an older era where you can spend hours tweaking conf files.
I disagree. Spending hours tweaking conf files was the norm back in the 90s out of necessity, but the idea of customizing your tools to suit yourself is not specific to that era. I'm young enough to not remember most of the 90s and have used Linux for less than a decade, but I often spend time customizing my setup to suit myself better.
If they were using a custom malloc, then they should have been memset (or similar) to zero the blocks when debugging. That way, use-after-frees still manifest as crashes when testing (it could be disabled in release builds to improve performance).
I'm in no way an experienced C programmer, but if I were reimplementing something as core as malloc/free I would include a ton of sanity checks and safeguards to make sure that, at least on debug builds, this sort of bug was obvious.
But wanting a GC has nothing to do with "brain dead idiots". It has been established decades ago that manual memory management is simply prone to errors, as program size increases. That includes expert programmers. This is a settled empirical question. If the overhead is acceptable, there is little reason to not want a GC.
There is also a third option: manual memory management with compile-time guarantees of safety. You get the performance of manual memory management without the risks, and the code ends up being more concise because heap allocation is implemented as a syntax feature. Rust is the most well known example of this.
Then again, you could just pick full C++ 11, which has the advantages of both the higher level of abstractions like C#, and the low level capabilities of C.
Speaking as someone who has worked with both C++11 and C#, C# is a much nicer language. C++11 improves things somewhat, but it's an old language and the cruft shows. The obvious example is generics: C#'s generics are quite straightforward to use, support constraints (base classes of type parameters), and can even be annotated to handle inheritance correctly. C++'s templates are notorious for their poor usability, to the extent that even Stroustrup recognizes that they fall short. A future version of C++ is supposed to implement Concepts, which provide the ability to add arbitrary constraints to type parameters (but not by using inheritance*, for some reason.)
It's quite telling that even though I've been using Linux as my primary OS for a few years now, I still haven't found a language that's as pleasant to use on it as C# was under Windows. (Qt is much nicer than the .NET Framework though.)
*To be fair, inheritance has the problem that once a class is written, you can no longer add base classes to it. But this is not insurpassable; C# supports extension methods that could be used to fix this in a manner similar to Haskell's type classes.
I avoided bluetooth for years becuase it was unreliable and awkward. The headsets were expensive and uncomfortable. Some didn't work in that they required pairing every time you turned it on. (Both the phone and the device completely forgot about each other.) Buying a corded headset was far cheaper, had far better quality, and was far more comfortable.
But times change, as do needs. Most bluetooth devices now have just enough non-volatile memory to remember what they were last paired with and most bluetooth hosts will quite happily keep a list of every device it's ever pair with. Other than the initial setup (which can still be awkward and annoying) it's quite simple to use now. Hold the button for a few seconds until the light blinks and/or the sound chimes. Now I have a whole host of bluetooth devices.
It's funny you mention this, given that just a few days ago I struggled and eventually gave up on getting my laptop to pair with a Bluetooth ODB adapter that had previously paired with a different laptop. (In the end I gave up, took it apart, and soldered some wires directly to the serial interface inside it, as I had a USB UART adapter on hand).
The problem was that the device kept disconnecting after I connected to it, and there was nothing I could do to convince it otherwise. The more complex a technology is, the harder it is to get the interface right. This goes doubly when you have an embedded system without a second, more powerful interface (compare this to how Linux supplements the GUI with a terminal). Wearable devices take this to an extreme; the interface is more limited than that of a phone, so it's even harder to get right.
For various reasons, functional langugaes are not always a realistic option in you project (especially if you're not starting from scratrch)
The same could be said about elegant code. :P
So in other words, most code written in a functional programming language. e.g. Haskell