We're currently in an adjustment where lots of people lose their jobs and are looking for other ones. This, like all such adjustments, will take years or decades under the best of circumstances. Therefore, it doesn't matter if self-driving vehicles aren't ready for prime time now, as long as it will happen in the next five to ten years. Also, they aren't going to be expensive for long. My car can already do its own acceleration, braking, and steering, and it does keep track of things outside the car to provide adaptive cruise control, collision avoidance, and a warning that something is moving more or less behind me when backing up. It cost me something like $30K. It wouldn't take much more to make it autonomous.
First, scarce resources are scarce. Just because making stuff is trivially cheap doesn't mean that everything is. Land, for example, can't be manufactured. Manufacturing robots will only exist in limited (if very large) quantities.
Second, people have to have a way to get money. If gourmet-class meals for a family of four cost a dollar a year, and you're broke, you starve.
The US government takes money from its citizens primarily through FICA and income taxes. The income taxes do not take money regardless of their ability to pay, and the FICA stuff is straight proportionate to money earned. Sales and property taxes can be regressive, but those are the domain of the states. As far as who needs help, the refugees are in a considerably worse situation, and there's no reason besides Republicans that we can't help both groups. Clinton, for example, had plans to help poor Americans. She isn't charismatic, but she's intelligent and effective.
Rightist ideology depends on lies, as demonstrated by the protests against refugees that ignore the rigorous vetting process, countries that haven't sent us terrorists, and this stupid idea that we can't help both Americans and others.
If a is a pointer, if(a) tests a against the null pointer. This is unnecessary because free(NULL) works. It's also deceptive since a non-null pointer doesn't have to point to anything useful, and free(a) doesn't set a to the null pointer. I've seen heavy use of macros in C, where the macro executes free(a);a = NULL;.
Elevating anything in software development to the level of a religion (except vim over emacs) is as crazy as any other religion. Similarly, saying that a developer should use a language construct where inappropriate because it might be appropriate in another application is crazy. Obviously, you're going to use jumps in assembly code, but you need to examine them to make sure they're doing what they should. In C, most applications of goto should be replaced by appropriate control structures that make it obvious what they're doing and reduce the chance of mistakes.
Incidentally, Forth suffered from a similar readability problem
I always found well-written and reasonably documented Forth readable. By documented, I mean each word has an inline comment showing what it does to the stack, and everything has meaningful names. I thought Forth was a lot of fun, and where else do you find ": ? . !;" to be part of a language definition?
The problem with eval() is that it's incredible power can't be used safely in most languages,
There are language constructs that should be used only in limited contexts. I'd look at an "eval" in application code as suspiciously as I'd look at "delete" in C++ application code. Both are commonly done by programmers who don't quite know how to use the language.
Multi-inheritance I never found very useful, even single-inheritance is rarely a good solution and you are better of doing composition most of the time.
Not in my experience, which may well be different from yours. There are situations where inheritance is exactly what you want (typically if you have a definite IS-A relationship with no gotchas which would violate the Liskov substitution principle*). Faking it with composition would be clumsy and unnecessary. You do need to have a good idea where inheritance is appropriate and where composition is. If most of your classes use other classes through inheritance, you're probably doing it wrong.
*The Liskov Substitution Principle is a little technical, but the general idea is that, if B inherits from A, members of A have to be expressible as members of B. For example, a square is a rectangle, but you can't represent a 2x4 rectangle as a square, so having Square inherit from Rectangle would violate the LSP.
There's other patterns that work with multiple inheritance, such as only one superclass having superclasses of its own. This allows "mixin" classes, which provide one specific behavior. We make extensive use of these, and don't have problems with them.
What you're finding more awkward in C++ inheritance has nothing directly to do with inheritance, but with C++ resource management. There's no problem with including a virtual destructor on every class you don't mark "final". The rule of three/five exists because a class may own resources that have to be cleared out or dealt with on destruction, and the C++ lack of a reference type distinction. With garbage collection and no destructors (finalizers are not destructors), Java makes cleaning up memory a lot easier and cleaning up anything else more difficult, but by removing resource management from the class structure it does make inheritance easier to get right.
Pascal was originally implemented on a CDC 6600, which had no call stack. (The way to call a subroutine was a Return Jump, which jumped to a particular memory word and wrote a jump back in the word before the subroutine, so the subroutine jumped to its own location - 1 a the end.
So, who determines whether a UN member has the internationally recognized attributes of statehood? And what are they? Without knowing the process of declaring failure of attributes of statehood, it's not possible to tell whether the action is legal or not.
Something like a decade ago, I tried throwing out everything I'd been taught about program optimization and just optimizing for cache use. The speedup was remarkable.
This is what destructors do in C++. Some languages have try...finally. In most modern languages, if your cleanup is freeing memory, you just leave it for the garbage collector.
Eval is not something to be used casually, but it's vital to how some languages work. My general rule is that, if you use it while writing application code, it's probably a mistake, but it can be very useful in libraries to do things and the like. Much like C++ template metaprogramming: very powerful, and most people should leave it for someone else to write.
We use multiple inheritance on the basis that a certain size of block has specific processing, and different blocks can be made of different materials. It seems to do a great job of keeping the complexity under control in our particular use case.
There are recursive algorithms that are important and not implementable as loops without auxiliary stacks. The loop formulations of these algorithms tend to be harder to read.
As someone who has worked with complicated C++ software for something like fifteen years, inheritance is very valuable. It keeps some of our core concepts understandable. It can clearly be overused, of course, but that's true of all language constructs.
Inheritance in Java is also more limited than inheritance in C++. One of the design goals of Java seems to have been to produce a safer C++ at the cost of expressive power.
Exceptions are for exceptional situations, and make handling them easier. (If they don't, don't use exceptions.) If people used goto only in exceptional situations, or only where it was clearer than the alternatives, Dijkstra would never have written against it.
You're missing the point of language abstractions. Ideally, we write our program in an easy-to-understand manner, and the compiler makes it run efficiently. In practice, this doesn't work as well as we'd like, but we're specifically talking here about a compiler that does what we really want.
One of the reasons I use higher-level languages is that abstracting away the details works a lot better than paying attention to them. If I use a break; in a for loop, I know at a glance what it's doing. If I substitute a "goto", I have to pay attention to the target line. Switches work more like if...else constructs than gotos, unless you're using something like Duff's device.
Slashdot Mirror
We're currently in an adjustment where lots of people lose their jobs and are looking for other ones. This, like all such adjustments, will take years or decades under the best of circumstances. Therefore, it doesn't matter if self-driving vehicles aren't ready for prime time now, as long as it will happen in the next five to ten years. Also, they aren't going to be expensive for long. My car can already do its own acceleration, braking, and steering, and it does keep track of things outside the car to provide adaptive cruise control, collision avoidance, and a warning that something is moving more or less behind me when backing up. It cost me something like $30K. It wouldn't take much more to make it autonomous.
Two problems.
First, scarce resources are scarce. Just because making stuff is trivially cheap doesn't mean that everything is. Land, for example, can't be manufactured. Manufacturing robots will only exist in limited (if very large) quantities.
Second, people have to have a way to get money. If gourmet-class meals for a family of four cost a dollar a year, and you're broke, you starve.
The US government takes money from its citizens primarily through FICA and income taxes. The income taxes do not take money regardless of their ability to pay, and the FICA stuff is straight proportionate to money earned. Sales and property taxes can be regressive, but those are the domain of the states. As far as who needs help, the refugees are in a considerably worse situation, and there's no reason besides Republicans that we can't help both groups. Clinton, for example, had plans to help poor Americans. She isn't charismatic, but she's intelligent and effective.
Rightist ideology depends on lies, as demonstrated by the protests against refugees that ignore the rigorous vetting process, countries that haven't sent us terrorists, and this stupid idea that we can't help both Americans and others.
The 1989 ANSI standard didn't remove any functionality, but made the language cleaner. If it would be awkward in C89, it would be awkward in K&R C.
If a is a pointer, if(a) tests a against the null pointer. This is unnecessary because free(NULL) works. It's also deceptive since a non-null pointer doesn't have to point to anything useful, and free(a) doesn't set a to the null pointer. I've seen heavy use of macros in C, where the macro executes free(a);a = NULL;.
Elevating anything in software development to the level of a religion (except vim over emacs) is as crazy as any other religion. Similarly, saying that a developer should use a language construct where inappropriate because it might be appropriate in another application is crazy. Obviously, you're going to use jumps in assembly code, but you need to examine them to make sure they're doing what they should. In C, most applications of goto should be replaced by appropriate control structures that make it obvious what they're doing and reduce the chance of mistakes.
I always found well-written and reasonably documented Forth readable. By documented, I mean each word has an inline comment showing what it does to the stack, and everything has meaningful names. I thought Forth was a lot of fun, and where else do you find ": ? . ! ;" to be part of a language definition?
There are language constructs that should be used only in limited contexts. I'd look at an "eval" in application code as suspiciously as I'd look at "delete" in C++ application code. Both are commonly done by programmers who don't quite know how to use the language.
Not in my experience, which may well be different from yours. There are situations where inheritance is exactly what you want (typically if you have a definite IS-A relationship with no gotchas which would violate the Liskov substitution principle*). Faking it with composition would be clumsy and unnecessary. You do need to have a good idea where inheritance is appropriate and where composition is. If most of your classes use other classes through inheritance, you're probably doing it wrong.
*The Liskov Substitution Principle is a little technical, but the general idea is that, if B inherits from A, members of A have to be expressible as members of B. For example, a square is a rectangle, but you can't represent a 2x4 rectangle as a square, so having Square inherit from Rectangle would violate the LSP.
There's other patterns that work with multiple inheritance, such as only one superclass having superclasses of its own. This allows "mixin" classes, which provide one specific behavior. We make extensive use of these, and don't have problems with them.
What you're finding more awkward in C++ inheritance has nothing directly to do with inheritance, but with C++ resource management. There's no problem with including a virtual destructor on every class you don't mark "final". The rule of three/five exists because a class may own resources that have to be cleared out or dealt with on destruction, and the C++ lack of a reference type distinction. With garbage collection and no destructors (finalizers are not destructors), Java makes cleaning up memory a lot easier and cleaning up anything else more difficult, but by removing resource management from the class structure it does make inheritance easier to get right.
Pascal was originally implemented on a CDC 6600, which had no call stack. (The way to call a subroutine was a Return Jump, which jumped to a particular memory word and wrote a jump back in the word before the subroutine, so the subroutine jumped to its own location - 1 a the end.
So, who determines whether a UN member has the internationally recognized attributes of statehood? And what are they? Without knowing the process of declaring failure of attributes of statehood, it's not possible to tell whether the action is legal or not.
Hey, I was congratulating myself for not writing "GIFs at 11". Thing about getting with the times is that it never stops, I guess.
Something like a decade ago, I tried throwing out everything I'd been taught about program optimization and just optimizing for cache use. The speedup was remarkable.
This is what destructors do in C++. Some languages have try...finally. In most modern languages, if your cleanup is freeing memory, you just leave it for the garbage collector.
Eval is not something to be used casually, but it's vital to how some languages work. My general rule is that, if you use it while writing application code, it's probably a mistake, but it can be very useful in libraries to do things and the like. Much like C++ template metaprogramming: very powerful, and most people should leave it for someone else to write.
Exceptions do things that are hard to do without them. Most uses of goto can be better written as something else.
We use multiple inheritance on the basis that a certain size of block has specific processing, and different blocks can be made of different materials. It seems to do a great job of keeping the complexity under control in our particular use case.
There are recursive algorithms that are important and not implementable as loops without auxiliary stacks. The loop formulations of these algorithms tend to be harder to read.
Beware of arguments that seem rational and are not based on experience.
As someone who has worked with complicated C++ software for something like fifteen years, inheritance is very valuable. It keeps some of our core concepts understandable. It can clearly be overused, of course, but that's true of all language constructs.
Inheritance in Java is also more limited than inheritance in C++. One of the design goals of Java seems to have been to produce a safer C++ at the cost of expressive power.
Exceptions are for exceptional situations, and make handling them easier. (If they don't, don't use exceptions.) If people used goto only in exceptional situations, or only where it was clearer than the alternatives, Dijkstra would never have written against it.
You're missing the point of language abstractions. Ideally, we write our program in an easy-to-understand manner, and the compiler makes it run efficiently. In practice, this doesn't work as well as we'd like, but we're specifically talking here about a compiler that does what we really want.
That's twisted. My own instinctive way to do it would be the first ..., then if (!exit_cond) ....There's no reason to use a "goto" here.
One of the reasons I use higher-level languages is that abstracting away the details works a lot better than paying attention to them. If I use a break; in a for loop, I know at a glance what it's doing. If I substitute a "goto", I have to pay attention to the target line. Switches work more like if...else constructs than gotos, unless you're using something like Duff's device.