It is char* and has certainly been stored on the heap because everything is instantiated via malloc
Except in your example, where one of them was a string literal (so const char * and definitely not safe to free) and the other was a heap-allocated char*. This means that you're either having separate functions for string literals vs malloc'd strings, or you're always responsible for manually freeing the second one. In contrast, if you did this in C++, then your string class would have a constructor that took a const char * and set the don't free flag by default, and you'd get implicit conversion automatically.
In one of the first versions of that approach, I accounted for more complex scenarios but everything became too buggy and problematic. So, finally I decided to rely on the shown simple structure and, for complex situations, I simply rely on (+ free) temporary variables by calling these methods as many times as required. Once you get used to the format, it is quite intuitive.
It may be simpler, but now you're doing a lot of redundant memory allocation, a lot of redundant copying, and tying all consumers of your code to the implementation of your data structure. I doubt that the performance will be better than doing the same thing in a scripting language (probably worse, because most scripting languages have fairly well optimised string implementations), so you're doing manual memory management to get worse performance.
Under my specific conditions where performance is a very important aspect, C seems a better option
Performance is a very important aspect... and yet you're willing to use O(n) algorithms and lots of malloc / free calls in places where constant-time algorithms would work with far fewer malloc / free calls and with much better cache usage?
This is the real problem with the 'C is fast' mentality: a good algorithm almost always beats a bad algorithm by a far larger margin than a fast language implementation beats a slow language implementation, and C is forcing you to use a worse data structure and algorithm than C++. No matter how much you tune your C code, it's going to be slower than if you'd used a better algorithm.
You don't, by any chance, work on Enlightenment do you?
Java doesn't guarantee anything with regards to timeliness of object destruction. A small object that just encapsulates a file descriptor may never be collected (until program exit - I think Java requires all objects are collected on program exit), and so its finaliser may never run and free the file handle while the program is executing. The same applies to closures - they're just objects and are not guaranteed to be deallocated.
Your approach seems fine at first glance, but it looks like it would struggle when you get more complex data flow. Even in your three-line example, I have a few questions:
What is the type of stringVariable? If it's char*, then how do I know when it's been stored on the heap and read back that it's dynamically allocated on the heap and so needs freeing?
What are the ownership semantics of the first argument to StringAction_m? Since you're assigning the result to the input variable, I presume that it's taking an owning reference and explicitly destroying it?
What happens when you have types that have more complex destruction than a simple free? For example, if you're doing a lot of string processing you probably want some kind of twine abstraction so that you don't end up doing a lot of temporary copies, but now your string data type is a linked list internally and just calling free on the first element will give you a memory leak.
With a C++ equivalent, none of these problems arise. Your string type would be a wrapper that would know if it owned the memory. On-heap character arrays would probably be represented with std::shared_ptr, so that you could store them in multiple twines before writing them to flat containers. Your different string representations would expose a common iterator type and allow you to query the strings without having to always store them in sequential memory.
TL;DR: It's not a question of what you can do in a language, it's a question of what you can do without thinking. I'd much rather have a language where the compiler deals with these issues and raises an error if I write something invalid than one where I have to be very careful to get things right that are going to be security issues if I get them wrong.
I'm not sure what point you're trying to make. It is very common to have an object where you want compile-time specialisation for some common (or hot-path) cases, but want a generic version for other cases, and want to share the implementations. Having an object that is both GC'd and non-GC'd at the same time seems like an odd requirement, though MSR had a paper at PLDI providing memory-safe manual memory management in the.NET context, where objects could be explicitly deallocated and would eventually be collected, so if you used a dangling to them you'd get an exception. Perhaps that what you want?
Okay, so how in C++ would you implement a variation on std::array that lets you select per use whether the size is a compile-time constant or a field that is set in the constructor?
Mozilla has run a very large-scale C++ project for many years, with an elite team of developers
If you've ever looked at the Mozilla code base, then you'd be a lot more reluctant to describe their team of developers as 'elite'. The most positive thing I can say about it is that it's not as bad as OpenOffice.
I've recently started using C++ for a bunch of things where I would previously have used a scripting language. It has basically everything I want from such a language:
Closures (including compile-time specialisation with C++14 auto parameter lambdas).
A rich set of collection classes (written by people who actually care about performance).
Regular expressions.
Smart pointers (so I don't need to think about memory management)
Futures / promises and threads.
A tiny dependency footprint (so my code will run on pretty much any *NIX system)
Most of the time, I can compile at -O0 and run in less time than it takes the Python interpreter to start and if I find that performance actually does matter then I can quickly profile it, find the bottleneck, and replace it with something a lot more efficient.
It's not always so clear cut. What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimisations. To give a trivial example, languages like Java provide an abstraction that looks like a C struct, but don't require that the memory layout be visible to the programmer. Imagine that you create a struct-like Java object with RGB values to represent a colour and you do the same in C. Now you put them in an array and try to do some processing on them. The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes). The Java version, in contrast, is allowed to put an unused padding field at the end of the struct. Why does that matter? If you want to vectorise the loop, then being able to guarantee 4-element alignment for every object in the array is a huge win. This is a legal transform for a Java compiler, but not a legal transform for a C compiler unless it can prove that no pointers to the array escape (and a few other constraints).
The big advantage of C was that a fairly simple compiler for a simple architecture could get very good performance. The disadvantage for C is that compilers quickly hit diminishing returns and the abstract machine makes a number of desirable optimisations unsound.
For example, if your language has a first-class notion of immutability, then this gives the compiler the opportunity to elide copies or add copies if they make sense for NUMA systems, and gives the compiler a lot more freedom with regard to reordering or eliding loads. Similarly, if your source language has higher-level notions of sharing then this means that you can avoid a lot of defensive memory barriers that you'd need for correct C/C++ code. If your language has stricter guarantees on aliasing, then a whole lot of optimisations suddenly become easier.
Any compiler optimisation is a mixture of two things: an analysis and a transformation. The analysis must be able to tell you if the preconditions for the transform are met. The more information you can give to the compiler, the more often the analysis can prove that the preconditions hold and enable the transform.
C++ has improved a lot, but there's still one place where it lags behind something like Lisp: you have to decide between compile-time and run-time specialisation very early. Constexpr functions were a big step in the right direction here, letting you move between compile-time and run-time computation without shifting syntax, but there's still no equivalent for data. If you want to do compile-time specialisation, you use templates, if you want to do run-time specialisation then you use fields. If you picked one and now want to move to the other, then it's very difficult to refactor, and if you want either compile-time or run-time specialisation in the same object for different uses then it gets clunky very quickly.
Sorry, I should have been more explicit. Messages sent over channels establish a happens-before relationship, but not with respect to any other memory operations. Everything else is non-atomic. That's fine in a language like Erlang, which doesn't allow mutable shared state (in Erlang, the only mutable object is the process dictionary, which cannot be shared), or Pony (and, I think, Rust) where the type system guarantees that no object is both shared between threads and mutable at the same time. In Go, the language makes it easy to share pointers to mutable objects, but then doesn't provide any guarantees about ordering or synchronisation for accesses to them.
Go tells people to 'share data by communicating', which basically means that you shouldn't share mutable data you should share channels that are used to serialise operations on mutable data. That's fine as a programming model, but the language provides absolutely no help (either in the type system or the tooling) to ensure that code actually follows this model. If ESR's complaint about C++ is that it requires programmers to follow 'well, don't do that' rules, then he should hate Go, because the only way of using it to write correct programs is to carefully avoid doing something that the language makes easy to do accidentally. At least with C++, it's relatively easy to audit code for violations of the C++ Core Guidelines. It's practically impossible to audit Go code for sharing of pointers to mutable state (in the general case, Go's subtyping model means that it reduces to the halting problem, in the common case it's just really, really hard).
My favourite thing was that YouTube then auto-played more Samsung vs Apple adverts from over the years. The first one was of the Galaxy S5, mocking the iPhone for its non-removable battery by having a cluster of iPhone users at an airport all huddled around a charging station while the Samsung guy just swapped his battery. The new Samsung phone has a non-removable battery. I wonder how something goes from the thing that you use to differentiate from your competition to a missing feature so quickly...
Arguing that it's harder for large-scale projects to manage a 'well, don't do that' approach implies that he's completely missed the last 40 years of tool development. This is much more of a problem for small C++ projects than large ones. Large ones have pre-push hooks that run static checkers that enforce rules like no bare pointer and no operator new / delete. It's the smaller ones that rely on programmer discipline to do this that are more likely to have problems.
Go is a horrible language. It has multithreading as a core part of the language, but no memory model and no type system that can express notions of sharing or immutability. The designers clearly realised that generic types are important, and so added precisely one to the language (the map type, which is parameterised on the key/value types). It has a map type that maps from one object type to another, but no way for users to define what equality (or ordered comparison or hash) means on objects.
The point is precisely that you need to pay to skip content which is in the game just to waste your time and is not enjoyable
If there is enough boring content in it that paying $2100 to skip it seems to make economic sense, then that's a great argument for not buying it in the first place. I don't care so much about the loot boxes, but if a game developer is willing to spend effort intentionally making their game not fun (EA normally manages that accidentally) then that always seems a pretty good reason to avoid it.
Net neutrality isn't a legal debate it's an ethical debate
If you phrase it as an ethical debate, then you've already lost. If you want people in Washington to care, phrase it as an economic debate: companies like Google, Facebook, Netflix, Amazon, Yahoo! and so on are possible because of network neutrality. How much do they contribute to the US economy in comparison to the ISPs? How much did the growth of the open Internet contribute in comparison to the likes of AOL and CompuServe?
There was a crowdfunding effort to buy the web browsing records of all politicians that voted to allow ISPs to sell these records and publish them online. Probably worth adding him to the list.
Or, alternatively, without money, it takes over 4500 hours of gameplay to unlock everything!
So, what you're saying is, if you pay $2100 then you get to play the game a lot less, and the more you pay the more you get to avoid playing the game? If that's an incentive then I've got a better deal: for $0, you can not play the game at all!. How many other black-friday sales save you 100%?
Someone (Matsushita?) demoed one of those earlier this year. Well, not quite, but very close: it was a wardrobe with a clothes bucket at one end. You had to drop the dirty clothes into it, but then it would sort them, wash them, dry them (by laying them on a flat surface and sucking the moisture out, which worked to iron them as well), fold them, and put them back in the correct place ready for you to wear.
Our new (cheap!) dishwasher seems to work fine in the usage pattern that you describe. The older model that it replaced worked best if we put it on to rinse after a partial load: the 10-minute rinse cycle cleaned enough to prevent dirt drying onto the dishes and was cheap to run.
Most dishwashers are the same now. There's an EU law that requires spare parts to be available for all white goods for 10 years. The unintended consequence of this is that developing bespoke parts is very expensive, because you have to either guarantee production of them for 10 years after the last dishwasher, or stockpile enough that you can guarantee being able to sell them to anyone who asks. That's a huge expense and so now dishwashers are all made from the same set of parts from the same small number of suppliers.
We just bought a fairly cheap model that replaced an older second-hand model that died after a few months. The new one is a huge improvement.
The problem with the robots described in TFA is diminishing returns. If you replace spending 10 minutes every day of washing up with spending 3-4 minutes every 2-3 days unpacking the dishwasher, then that's a big time saving and well worth it. If you then save that time, it's a much smaller saving.
It's the same problem for robot vacuum cleaners. I'd love to have one, but vacuuming doesn't take that long and the biggest time sink is moving furniture to vacuum around and under it. One intelligent (and small) enough to go under and around furniture and to tell the difference between a clump of hair that I want vacuumed up and a dropped nut or bolt that I really don't want vacuumed up would be a huge time saver. The current models automate the easy bit of the job, but leave the time-consuming bit for me.
You are about as likely to get a frostbite from a shot of vodka out of freezer as you are to get it from eating an ice cream.
Vodka in the freezer will reach minus 18 degrees centigrade, which is easily enough to cause frostbite. Icecream doesn't have the same effect because you don't throw it down your throat, so it's not completely coating any part of you, and because it's solid and so the heat spreads through it slowly and you quickly get a warmer insulating layer of melted cream on the surface of your mouth (and coating your throat if you swallow the ice lump).
If you want to support pointer-arithmetic and GC in the same context, you could do it by differentiating the GC kind of pointer ('references', if you like) from non-GC pointers, right?
Pointer arithmetic isn't a problem, as long as you can identify that the results are still pointers and you can prevent a pointer from one object becoming another kind. The C implementation that we've built does that - if a pointer goes out of range, it's an out-of-range pointer to the original object, so you can't dereference it until you bring it back in range, but the GC can still find the object that it refers to.
Again I think D supports this - you can do malloc/free and implement XOR linked lists, and you can do GC'able objects, in the same process. I think the type system prevents anything too awful from happening, as pointer arithmetic isn't allowed on (GC'ed) references and the two kinds aren't convertible.
That's fine, as long as you trust the compiler (and any hand-written assembly) to play by the rules. I'm trying to get the million of so lines of a typical optimising compiler out of the TCB for memory safety.
You have to get it pretty cold to freeze vodka. About 10 years ago, there were a bunch of news stories from people storing vodka in the freezer and then doing shots. Apparently the most likely outcome is frostbite on your throat.
Really? I use wine on macOS and generally it's a matter of clicking the create wrapper button in the Wineskin app, and then dragging the installer onto the install button, and then I have a Mac.app that wraps the game. I don't have to do it much anymore, because GOG now does it for me for a lot of games.
Access gets a bad rap, but it's actually a pretty good tool for its intended purpose: a RAD tool for developing a database front end. If your data is actually stored in Access then either you're prototyping or you're doing it wrong, but if your data is stored in a real database then Access is a pretty good way of quickly generating forms that interface it that you can roll out in your organisation (though web interfaces are largely obsoleting it these days).
They do now, because it's a small proportion of the total. If, however, Google moved YouTube and its other services over to another protocol that isn't amenable to in-flight inspection, and made Chrome default to using this protocol, then ISPs would quickly find that they're getting complaints that people can't watch videos on their 20Mb/s connection and wanting to know why.
Slashdot Mirror
It is char* and has certainly been stored on the heap because everything is instantiated via malloc
Except in your example, where one of them was a string literal (so const char * and definitely not safe to free) and the other was a heap-allocated char*. This means that you're either having separate functions for string literals vs malloc'd strings, or you're always responsible for manually freeing the second one. In contrast, if you did this in C++, then your string class would have a constructor that took a const char * and set the don't free flag by default, and you'd get implicit conversion automatically.
In one of the first versions of that approach, I accounted for more complex scenarios but everything became too buggy and problematic. So, finally I decided to rely on the shown simple structure and, for complex situations, I simply rely on (+ free) temporary variables by calling these methods as many times as required. Once you get used to the format, it is quite intuitive.
It may be simpler, but now you're doing a lot of redundant memory allocation, a lot of redundant copying, and tying all consumers of your code to the implementation of your data structure. I doubt that the performance will be better than doing the same thing in a scripting language (probably worse, because most scripting languages have fairly well optimised string implementations), so you're doing manual memory management to get worse performance.
Under my specific conditions where performance is a very important aspect, C seems a better option
Performance is a very important aspect... and yet you're willing to use O(n) algorithms and lots of malloc / free calls in places where constant-time algorithms would work with far fewer malloc / free calls and with much better cache usage?
This is the real problem with the 'C is fast' mentality: a good algorithm almost always beats a bad algorithm by a far larger margin than a fast language implementation beats a slow language implementation, and C is forcing you to use a worse data structure and algorithm than C++. No matter how much you tune your C code, it's going to be slower than if you'd used a better algorithm.
You don't, by any chance, work on Enlightenment do you?
Java doesn't guarantee anything with regards to timeliness of object destruction. A small object that just encapsulates a file descriptor may never be collected (until program exit - I think Java requires all objects are collected on program exit), and so its finaliser may never run and free the file handle while the program is executing. The same applies to closures - they're just objects and are not guaranteed to be deallocated.
What is the type of stringVariable? If it's char*, then how do I know when it's been stored on the heap and read back that it's dynamically allocated on the heap and so needs freeing?
What are the ownership semantics of the first argument to StringAction_m? Since you're assigning the result to the input variable, I presume that it's taking an owning reference and explicitly destroying it?
What happens when you have types that have more complex destruction than a simple free? For example, if you're doing a lot of string processing you probably want some kind of twine abstraction so that you don't end up doing a lot of temporary copies, but now your string data type is a linked list internally and just calling free on the first element will give you a memory leak.
With a C++ equivalent, none of these problems arise. Your string type would be a wrapper that would know if it owned the memory. On-heap character arrays would probably be represented with std::shared_ptr, so that you could store them in multiple twines before writing them to flat containers. Your different string representations would expose a common iterator type and allow you to query the strings without having to always store them in sequential memory.
TL;DR: It's not a question of what you can do in a language, it's a question of what you can do without thinking. I'd much rather have a language where the compiler deals with these issues and raises an error if I write something invalid than one where I have to be very careful to get things right that are going to be security issues if I get them wrong.
I'm not sure what point you're trying to make. It is very common to have an object where you want compile-time specialisation for some common (or hot-path) cases, but want a generic version for other cases, and want to share the implementations. Having an object that is both GC'd and non-GC'd at the same time seems like an odd requirement, though MSR had a paper at PLDI providing memory-safe manual memory management in the .NET context, where objects could be explicitly deallocated and would eventually be collected, so if you used a dangling to them you'd get an exception. Perhaps that what you want?
Okay, so how in C++ would you implement a variation on std::array that lets you select per use whether the size is a compile-time constant or a field that is set in the constructor?
Mozilla has run a very large-scale C++ project for many years, with an elite team of developers
If you've ever looked at the Mozilla code base, then you'd be a lot more reluctant to describe their team of developers as 'elite'. The most positive thing I can say about it is that it's not as bad as OpenOffice.
Most of the time, I can compile at -O0 and run in less time than it takes the Python interpreter to start and if I find that performance actually does matter then I can quickly profile it, find the bottleneck, and replace it with something a lot more efficient.
It's not always so clear cut. What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimisations. To give a trivial example, languages like Java provide an abstraction that looks like a C struct, but don't require that the memory layout be visible to the programmer. Imagine that you create a struct-like Java object with RGB values to represent a colour and you do the same in C. Now you put them in an array and try to do some processing on them. The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes). The Java version, in contrast, is allowed to put an unused padding field at the end of the struct. Why does that matter? If you want to vectorise the loop, then being able to guarantee 4-element alignment for every object in the array is a huge win. This is a legal transform for a Java compiler, but not a legal transform for a C compiler unless it can prove that no pointers to the array escape (and a few other constraints).
The big advantage of C was that a fairly simple compiler for a simple architecture could get very good performance. The disadvantage for C is that compilers quickly hit diminishing returns and the abstract machine makes a number of desirable optimisations unsound.
For example, if your language has a first-class notion of immutability, then this gives the compiler the opportunity to elide copies or add copies if they make sense for NUMA systems, and gives the compiler a lot more freedom with regard to reordering or eliding loads. Similarly, if your source language has higher-level notions of sharing then this means that you can avoid a lot of defensive memory barriers that you'd need for correct C/C++ code. If your language has stricter guarantees on aliasing, then a whole lot of optimisations suddenly become easier.
Any compiler optimisation is a mixture of two things: an analysis and a transformation. The analysis must be able to tell you if the preconditions for the transform are met. The more information you can give to the compiler, the more often the analysis can prove that the preconditions hold and enable the transform.
C++ has improved a lot, but there's still one place where it lags behind something like Lisp: you have to decide between compile-time and run-time specialisation very early. Constexpr functions were a big step in the right direction here, letting you move between compile-time and run-time computation without shifting syntax, but there's still no equivalent for data. If you want to do compile-time specialisation, you use templates, if you want to do run-time specialisation then you use fields. If you picked one and now want to move to the other, then it's very difficult to refactor, and if you want either compile-time or run-time specialisation in the same object for different uses then it gets clunky very quickly.
Sorry, I should have been more explicit. Messages sent over channels establish a happens-before relationship, but not with respect to any other memory operations. Everything else is non-atomic. That's fine in a language like Erlang, which doesn't allow mutable shared state (in Erlang, the only mutable object is the process dictionary, which cannot be shared), or Pony (and, I think, Rust) where the type system guarantees that no object is both shared between threads and mutable at the same time. In Go, the language makes it easy to share pointers to mutable objects, but then doesn't provide any guarantees about ordering or synchronisation for accesses to them.
Go tells people to 'share data by communicating', which basically means that you shouldn't share mutable data you should share channels that are used to serialise operations on mutable data. That's fine as a programming model, but the language provides absolutely no help (either in the type system or the tooling) to ensure that code actually follows this model. If ESR's complaint about C++ is that it requires programmers to follow 'well, don't do that' rules, then he should hate Go, because the only way of using it to write correct programs is to carefully avoid doing something that the language makes easy to do accidentally. At least with C++, it's relatively easy to audit code for violations of the C++ Core Guidelines. It's practically impossible to audit Go code for sharing of pointers to mutable state (in the general case, Go's subtyping model means that it reduces to the halting problem, in the common case it's just really, really hard).
My favourite thing was that YouTube then auto-played more Samsung vs Apple adverts from over the years. The first one was of the Galaxy S5, mocking the iPhone for its non-removable battery by having a cluster of iPhone users at an airport all huddled around a charging station while the Samsung guy just swapped his battery. The new Samsung phone has a non-removable battery. I wonder how something goes from the thing that you use to differentiate from your competition to a missing feature so quickly...
Arguing that it's harder for large-scale projects to manage a 'well, don't do that' approach implies that he's completely missed the last 40 years of tool development. This is much more of a problem for small C++ projects than large ones. Large ones have pre-push hooks that run static checkers that enforce rules like no bare pointer and no operator new / delete. It's the smaller ones that rely on programmer discipline to do this that are more likely to have problems.
Go is a horrible language. It has multithreading as a core part of the language, but no memory model and no type system that can express notions of sharing or immutability. The designers clearly realised that generic types are important, and so added precisely one to the language (the map type, which is parameterised on the key/value types). It has a map type that maps from one object type to another, but no way for users to define what equality (or ordered comparison or hash) means on objects.
The point is precisely that you need to pay to skip content which is in the game just to waste your time and is not enjoyable
If there is enough boring content in it that paying $2100 to skip it seems to make economic sense, then that's a great argument for not buying it in the first place. I don't care so much about the loot boxes, but if a game developer is willing to spend effort intentionally making their game not fun (EA normally manages that accidentally) then that always seems a pretty good reason to avoid it.
Net neutrality isn't a legal debate it's an ethical debate
If you phrase it as an ethical debate, then you've already lost. If you want people in Washington to care, phrase it as an economic debate: companies like Google, Facebook, Netflix, Amazon, Yahoo! and so on are possible because of network neutrality. How much do they contribute to the US economy in comparison to the ISPs? How much did the growth of the open Internet contribute in comparison to the likes of AOL and CompuServe?
There was a crowdfunding effort to buy the web browsing records of all politicians that voted to allow ISPs to sell these records and publish them online. Probably worth adding him to the list.
Or, alternatively, without money, it takes over 4500 hours of gameplay to unlock everything!
So, what you're saying is, if you pay $2100 then you get to play the game a lot less, and the more you pay the more you get to avoid playing the game? If that's an incentive then I've got a better deal: for $0, you can not play the game at all!. How many other black-friday sales save you 100%?
Someone (Matsushita?) demoed one of those earlier this year. Well, not quite, but very close: it was a wardrobe with a clothes bucket at one end. You had to drop the dirty clothes into it, but then it would sort them, wash them, dry them (by laying them on a flat surface and sucking the moisture out, which worked to iron them as well), fold them, and put them back in the correct place ready for you to wear.
Our new (cheap!) dishwasher seems to work fine in the usage pattern that you describe. The older model that it replaced worked best if we put it on to rinse after a partial load: the 10-minute rinse cycle cleaned enough to prevent dirt drying onto the dishes and was cheap to run.
Most dishwashers are the same now. There's an EU law that requires spare parts to be available for all white goods for 10 years. The unintended consequence of this is that developing bespoke parts is very expensive, because you have to either guarantee production of them for 10 years after the last dishwasher, or stockpile enough that you can guarantee being able to sell them to anyone who asks. That's a huge expense and so now dishwashers are all made from the same set of parts from the same small number of suppliers.
We just bought a fairly cheap model that replaced an older second-hand model that died after a few months. The new one is a huge improvement.
The problem with the robots described in TFA is diminishing returns. If you replace spending 10 minutes every day of washing up with spending 3-4 minutes every 2-3 days unpacking the dishwasher, then that's a big time saving and well worth it. If you then save that time, it's a much smaller saving.
It's the same problem for robot vacuum cleaners. I'd love to have one, but vacuuming doesn't take that long and the biggest time sink is moving furniture to vacuum around and under it. One intelligent (and small) enough to go under and around furniture and to tell the difference between a clump of hair that I want vacuumed up and a dropped nut or bolt that I really don't want vacuumed up would be a huge time saver. The current models automate the easy bit of the job, but leave the time-consuming bit for me.
You are about as likely to get a frostbite from a shot of vodka out of freezer as you are to get it from eating an ice cream.
Vodka in the freezer will reach minus 18 degrees centigrade, which is easily enough to cause frostbite. Icecream doesn't have the same effect because you don't throw it down your throat, so it's not completely coating any part of you, and because it's solid and so the heat spreads through it slowly and you quickly get a warmer insulating layer of melted cream on the surface of your mouth (and coating your throat if you swallow the ice lump).
If you want to support pointer-arithmetic and GC in the same context, you could do it by differentiating the GC kind of pointer ('references', if you like) from non-GC pointers, right?
Pointer arithmetic isn't a problem, as long as you can identify that the results are still pointers and you can prevent a pointer from one object becoming another kind. The C implementation that we've built does that - if a pointer goes out of range, it's an out-of-range pointer to the original object, so you can't dereference it until you bring it back in range, but the GC can still find the object that it refers to.
Again I think D supports this - you can do malloc/free and implement XOR linked lists, and you can do GC'able objects, in the same process. I think the type system prevents anything too awful from happening, as pointer arithmetic isn't allowed on (GC'ed) references and the two kinds aren't convertible.
That's fine, as long as you trust the compiler (and any hand-written assembly) to play by the rules. I'm trying to get the million of so lines of a typical optimising compiler out of the TCB for memory safety.
You have to get it pretty cold to freeze vodka. About 10 years ago, there were a bunch of news stories from people storing vodka in the freezer and then doing shots. Apparently the most likely outcome is frostbite on your throat.
Really? I use wine on macOS and generally it's a matter of clicking the create wrapper button in the Wineskin app, and then dragging the installer onto the install button, and then I have a Mac .app that wraps the game. I don't have to do it much anymore, because GOG now does it for me for a lot of games.
Access gets a bad rap, but it's actually a pretty good tool for its intended purpose: a RAD tool for developing a database front end. If your data is actually stored in Access then either you're prototyping or you're doing it wrong, but if your data is stored in a real database then Access is a pretty good way of quickly generating forms that interface it that you can roll out in your organisation (though web interfaces are largely obsoleting it these days).
They do now, because it's a small proportion of the total. If, however, Google moved YouTube and its other services over to another protocol that isn't amenable to in-flight inspection, and made Chrome default to using this protocol, then ISPs would quickly find that they're getting complaints that people can't watch videos on their 20Mb/s connection and wanting to know why.