I am skeptical about the novelty of Scala's "OOFP" as you put it. It looks essentially the same as the original anonymous classes or SAM types in Java. Function values are objects with a single method and methods themselves are not first-class, but are wrapped in objects as required. The most important part of OO are the first-class modules; and in the literature, arguably more elegant examples of unifying first-class modules and FP exist, for example by starting with FP and adding objects as records containing functions, this way both "objects" and methods would be first-class. Subtyping also adds significant complexity to the language and weakens type inference.
Scala is, first and foremost an OO language which embraces subtyping, class hierarchies and imperative programming, see for example its own collections library. As Java gets more and more FP features, there is a danger it will struggle to differentiate itself.
> You can do this in any language, functional or not.
No, not in practice. For example, in an average imperative language, you'd have no tail-call optimisation, and so would run out of stack space pretty quickly. There'd also be no persistent collections, meaning you'd have to keep copying any sets of values for every recursive call with absymal complexity. And so on...
Well, I have noticed significant degradation of 128kbps MP3 sources when sent over Bluetooth, whereas my FLAC CD rips sound fine. I don't think that the effects of transcoding are well understood or well-studied, especially the interaction between different codecs.
> Transcoding doesn't make much of a difference either.
I respectfully disagree. Transcoding does make an audible difference, at the bitrates typically used, and should have no place in "high fidelity" audio. My issue with these Bluetooth codecs is that they are not used at the sources and so will always be used in practice for transcoding.
My understanding is that music gets decompressed on the Apple headphones, the original AAC stream is sent over the wire. Most Bluetooth headphones will just effectively transcode the audio, such that for example AAC gets decompressed then recompressed into AptX/LDAC. For music listening, it's completely suboptimal. I use FLAC sources for my Sony headphones which makes them very listenable (along with copious EQ to tame the +5db excess bass). Bluetooth headphones have a lot of room for improvement.
AptX is lossy compression which when applied to already compressed sources (e.g. Spotify), still gives noticeably inferior audio (it's effectively transcoding).
Most people listen to compressed music and so the right thing to do with limited bandwidth is to send the original compressed data over Bluetooth (as Apple/Bose do with AAC). AptX is probably fine if you have non-lossy compressed sources like FLAC.
This isn't true. It was never as good as Intel's Connman, which was designed to be modular from the start. NetworkManager started out as a UI app and then was evolved into what it is now. It's still not as fast as connecting to WiFi as Connman.
I guess it was adopted instead of Connman because RedHat.
I, personally, wouldn't use VBA at all, ever. I would only consider Excel and Word for very simple use cases. For example, I refuse to use Word for technical documentation. But Office and Excel are everywhere in large corporates; and simple tactical spreadsheets turn into monsters over time. One former employer had a spreadsheet "application" where triggering a sheet recalc (accidentally) would take out an entire grid of machines. I've never been in any position to stop this stuff from happening.
Yes, every statically-typed language has a dynamic language as a subset. It is up to the author to use and apply types. One can certainly write Haskell where everything is in IO and everything uses Strings.
If you use String for all your data types than you are no better than a dynamic language. There are many string like things that benefit from their own types, e.g. currency, identifiers, post codes. Such types should only be created from a parse of valid strings, i.e. no empty strings, whitespace, illegal values etc. They do not have to be Alan Kay "objects", despite what your language or thought leadership is telling you. They should be values with value-based equality. A modern statically typed language should let you define such a type in a few lines. This is all done in order to make illegal states unrepresentable, which is what type systems are for.
The language and notation is inconsistent with hundreds of years of use in maths and confusing for kids learning both maths and programming (at least it confused me).
Regarding your skeptism of immutable data structures, it's best to think of immutable data and data structures as copy-on-write instead of update-in-place. This is a technique that is currently very underused, for example most programming languages do not come with "persistent" copy-on-write collections.
That's a bad choice of name from one or more old languages that misused established mathematical terminology (e.g. C misuses void, constant and variable). An immutable variable (or in maths, just "variable') has a value that is unknown at build time but is constant at runtime. A constant has a known value at build time.
What nearly every language calls a variable today, is probably better described as a "reference" or "assignable", but sadly that ship has sailed and we'll forever be inconsistent with the math terminology for that one. Immutable variable is therefore a useful synonym for "proper variable".
Well Brexit caused the pound to plummet and supposedly made ARM tempting. I find it ironic that the current UK Brexiteer government talk constantly about soveignty and control, yet were quite happy to allow this sale.
Objects don't have to have mutable state. And even if they do, it can be unobservable. This is true "state encapsulation" but the OOP definition of encapsulation does not require this. Such objects are still very useful as "first-class modules", i.e. modules that can be passed around and switched at runtime.
On my Kinesis Advantage I can type any letter whilst keeping my wrists straight, hands still and with much less finger movement than a regular keyboard. It completely cured my RSI and it hasn't returned in over 4 years. I realise this is anecdotal, but it's not really a surprise that a better key layout leads to less stretching and contortion and less RSI.
> I don’t know why everyone wants keyboard with a long throw,
Because one does not need to hit the bottom and "shock" the fingers in order to activate the keys. With a mechanical switch the keys can be activated by partially pressing them.
No, the biggest benefit is first-class modules. This is a feature that for example FP languages have struggled to incorporate. "Encapsulation" with OOP is a bit of a misnomer, as state is not encapsulated, it is just hidden. Such hidden state then interferes with composition. With true state encapsulation, a function can use mutation on the inside, but appear pure on the outside.
That depends on the programming language, for example C# with LINQ and functional programming languages are pretty good at expressing queries. SQL has no capability for abstraction and so only the simplest queries will be succint, if you want to e.g. union two similar queries then you'll have to copy and paste.
I recommend reading the original "Monads for Functional Programming" paper by Phil Wadler, it's in a tutorial style and IMHO still better than any blog post explanation I have seen:
> should the language catch us making a type error here?
With a statically typed language, the choice is up to you. Every statically typed language is just a "dynamically typed" language with the ability to statically assign types. For example, you can type the variable as an "Int" or for more runtime flexibility, a "Variant" (if using C++).
The problem with the Archimedes was that it arrived late on the scene and was very expensive. My school purchased only one; and none of us kids got to go anywhere near it. The Atari ST is what I moved to after my BBC micro, in about 86 or 87.
Many people buy Apple hardware because that's where most of the apps are, especially the iPad. I purchased an iPad for my kids for precisely this reason, and regarding the actual software that Apple provides, I am not at all impressed (e.g. app store is a mess, app approvals for kids is very broken). I am also aware that this extortionate 30% transaction cost is likely being passed on to me.
If I could get all the games and educational apps we use on the iPad on another platform, I would ditch Apple in a heartbeat.
It's perhaps less important because software can still be installed on Android without Google Play. Don't forget that Apple has already cut special deals with Amazon, so the extortionate 30% is negotiable, if one is big enough to fight.