1: There is nothing intrinsic to crypto that makes it go up. If demand (i.e. utilization) is not growing as fast as new coins are mined, then the value drops. This is even more pronounced when the utilization growth goes negative. See yesterday, and last month, and this whole year. BTC is currently worth less than half what it was last year, and has the potential to drop all the way to zero without major changes to the world we live in. USD by contrast would only be capable of dropping to zero by way of the apocalypse.
2: They are only as secure as the software that is used to handle it. Software in general is notoriously insecure. Also see 51% attack.
3: You can achieve this same effect using a brokerage service, of which there are millions in every flavour you could want. The easiest to use variants are Credit Cards which are accepted almost universally. Visa handles 150M transactions per day, or approximately 3 orders of magnitude more than bitcoin, and in spite of that high load, they handle individual transactions in seconds. Nothing about cryptocurrency is inherently faster, better or safer.
5: Only if they are universally accepted. If people stop accepting them, then they loose utility, and less people will be inclined to use them, which makes them even less useful. This is known as a death spiral, and the research cited in this story seems to indicate that bitcoin is headed in exactly that direction. This phenomenon is not unique to cryptocurrency, and is one of the reasons that AmEx plays dirty pool to force retailers to keep accepting their cards.
By the way, BTC is up 3.5% or so again since yesterday's drop
And now an hour and a half later its back down again.
There are only two institutional users of bitcoin now: Market manipulators and money launderers / tax evaders. Everyone else abandoned that ship, but the money launderers will prop up the price indefinitely because they are both the buyer and the seller. The only way crypto goes to zero is when the money launderers are stopped, and you can bet that tax agencies the world over are working on that problem as we speak.
The collapse wont be an overnight crash, just a long slow slide to oblivion as the launderers are either caught, or figure out that crypto is not anonymous enough to protect them, and fewer and fewer remain.
They randomly changed Mystreet Street to Mystreet Ave. You don't realize the amount of services that rely on Google for address verification until it starts throwing you errors about an invalid address. Fuck you Google, it still says Street on the signs and even on your goddamn streetview images.
If you think thats bad, you should see what happens when the 911 database (yes they keep their own address database based on the US postmaster postal standard) is wrong. At least with google you have some idea of whom to send an e-mail to. With 911, there is literally 1 person in the entire country who has the knowledge, the access and the authority to actually fix that problem for any given location, and good luck finding them. You can't even be sure what state they work in or what agency they work for. The collective group of them don't even know how to contact each other.
Considering how many S and X motor units they have replaced, the fact that they made the 3 one easy to replace doesn't inspire confidence. How old are the oldest 3s out there now? Maybe they are just being careful, if they had to do mass warranty replacements it would destroy them if it was as much work as the S/X.
The real need is actually much more acute. When a car is manufactured, the vehicle moves through the assembly process having parts installed. The number of steps in this process determines how long the assembly line needs to be. Just like a processor pipeline, when everything goes right, it doesn't matter how long the pipeline/assembly line is, you will still finish cars / instructions at the rate at which the slowest step can be performed.
If something breaks down in the pipeline/ assembly line somewhere, then the length of the line determines the penalty.
What tesla has done by having the entire axle assembly removable is to parallelize the assembly process so that a breakdown in the axle sub-assembly line doesn't impact the overall assembly line progress. Its a smart bit of engineering, and one of the many ways in which they are making cars that cost less to build while having better specs and better overall quality. The shorter the pipeline, the less defects have to be tolerated in order to make production rates.
Copyright was invented for the good of society. It was intended to provide some level of protection against the risk of creating original works and in exchange, people would create good works that society would benefit from. The original idea was a balance that provided maximum benefit to society. It has nothing to do with rights, and is the most poorly named concept in our legal/justice system which is saying something. These are privileges that our society chooses to impart on specific individuals and corporations.
What we have now, is a system whereby copyright exists almost exclusively for the profit of a few corporations at the expense of society (That which should be free isn't, and society has no access to these works except to continue paying the Danegeld.) Copyright law is broken. The original benefit to society that was envisioned has not played out, and either balance needs to be restored to the law (7 year terms tops), or the law needs to be eliminated completely as the miserably failed social experiment that it is.
The very idea that they are irrevocable rights is absurd on the face of it, and grants far too much authority to our government in the first place. I would submit that our government should not even have the authority to grant copypriviledge to anyone, and that this ill-gotten power should be stripped from the government at the soonest possible opportunity.
Copyright is government interference in the free markets and is fundamentally at odds with Republican small government and Democratic regulation of business. It is antithetical to every partys stated positions, so why is it perpetuated and made worse by each successive congress?
I want to know which logfile editor to use to read the journal.d or/etc/logs.
That would be journalctl. I don't know what the hot-key combo for emacs is, but you can be relatively sure there is one
For vi or emacs, you could do:
journalctl > foo
vi foo
but I'm not sure why you wouldn't just look at the output of journalctl directly. Its output can be piped through your favorite parsing and sorting programs just the same as if it you were directly reading from a file.
If you are talking about writing to the logs, then you should use the existing logging mechanisms in your programming language of choice, they still work the way they always did.
If you are talking about altering existing system logs, then I am going to say with all due rudeness, that you are talking about the Linux equivalent of altering official documents, and are either up to something nefarious, or are a blithering idiot, either way I see no reason to make your task any easier than it has to be.
At the end of the day, this is all about the fact that the world is not text based, it is based in far more complex and subtle data types, and it is time that the Unix/Linux weenies got with the program and dealt with the fact that \0 can and should be used for things other than the end of a string of text.
Around 2014, with the switch to Systemd, Debian started to decline in popularity. This was followed by the equally stunning change in Ubuntu to the same init system. By 2018, it was apparent that both distributions were headed to the scrap heap of history as they had lost nearly 80% of their user base in the 3 intervening years.
Oh, wait, that didn't actually happen? Debian/Ubuntu still has the same userbase in the Linux Desktop and Server markets it had before the Systemd change?
I guess the markets have spoken, and the predictions of doomsday were nothing more than the echo chamber effect of a very small and very vocal minority of people who do not appear to represent either Linux users or Linux developers as a whole. That is the only explanation that fits the facts.
How long an iteration of a loop takes to execute is irrelevant. What matters is the circumstances contributing to iteration count.
The number of iterations in many instances is fixed and cannot be improved. For example when processing the records in a database, you have to iterate over all of the records. Any reasonably sized database will have millions of records. The databases I deal with have trillions of records. Yuo certainly don't want to waste iterations, but thinking that the amount of processing in the record loop is irrelevant is ignorant.
Ivory tower? My code is routinely profiled against C implementations, and my code routinely wins. I have to know where every cycle goes because I have hard limits on wall clock execution time, and thanks to having actual data security, throwing cloud based resources at the problems to make up for lack of programming skill is not an option.
Using TMP, I can beat even the tightest inner loops written in pure C. I get paid good money to shave milliseconds, and at every step of the way I have to prove conclusively that my solutions are better than what was already there. The kind of work I do is very lucrative, but it weeds out the incompetent at a frightening rate, and there is a damn good reason I am one of the survivors.
Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground.
And yet here we are nearly 20 years later, and no one has a better alternative to TMP, and most languages don't offer anything at all.
When coding with assembly, programmers would use macros in the same way templates were used. You would define your macro with parameters defining the local name of each register storing that variable. Then if you wanted to reorder register usage, you just change the order of the parameters in the macro call.
I'm afraid you have not only missed the entire point of templates, but also their most powerful capabilities as well
Templates are for implementing the same function multiple times with variations between them, but without having to rewrite the whole function in every variation you want to implement. For example: (I apologize about the formatting)
template<tbool T_bRounded>
void foo()
{ //Do some stuff to find x
if( T_bRounded)
{
return( round(x));
}
else
{
return(x);
}
}
This simple function implements a call that either returns x, or rounds it first, and then returns it. The magic of the implementation is that the conditional on T_bRounded does not result in an actual jump instruction. Instead, the function is instantiated twice, once with the return in the if clause, and once with the return in the else clause. The correct function is called based on the template parameter that is used. For this simple example, it is not terribly useful, but imagine that foo has an inner loop where T_bRounded gates a particular behavior that is executed millions or billions of times. Not having that extra conditional jump in the assembled code will make a huge difference to the resulting compute time. That is a simple example of the real power of TMP. Imagine if you have a dozen such booleans that you want to gate out various behaviors from an inner loop. You could easily double or triple the speed of the inner loop. The only way to write competing code in C would be to write 4096 versions of the function with all possible combinations of the twelve flags, and call the correct one based on the flags using a jump table. What are the odds that you could write all 4096 without having a significant number of mistakes? With TMP, you write it once and the compiler spreads it out for you.
So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.
Think about it a little differently: There are a few primary goals when writing code. The first is speed of coding: how fast can the developers get the work done. The second is maintainability: How easy will it be to get new developers up to speed on the project, and how easy will it be for them to add new features. The Third is code performance.
Some languages address the first item very well. Python is a good example of a language that allows you to get something working very quickly. It can be maintainable or not depending largely on the quality of the code that is written and the presence (or lack) of comments. Python simply cannot be performant. It is an interpreted language, but even compiled, it cannot achieve high performance because it lacks the language constructs necessary to permit high performance computing.
Some languages address the second very well. Java was designed to be a language that follows a rigid pattern of development that should be very similar across projects. In theory this should allow a developer to come up to speed more quickly because there is only one way to do each thing that needs to be done. In practice, Java developers can write horrrendous code too, and for the similar reasons to Python, Java simply cannot be performant.
For the third, there are very limited options for raw performance. They really are: Assembler, C++ and C, in descending order of absolute performance (C++ might even edge out assembler now thanks to TMP. In theory you could implement the same thing in assembler, but good luck). Developers can write maintainable code in any of the three, or they can write junk. It really depends on the developer.
At the end of the day, the first two priorities can be had in any language depending on the skill of the developer, but the third priority can only be had in those three languages. It is due in no small part to those capabilities that C++ is as complicated as it is. It can do things that *no other language can do*.
In the end, if there is even the slightest possibility that performance will be a project priority, then you are limited to C, C++ or Assembler.
If one uses every single feature of C++, then it's probably a really terrible language.
If one only uses features that make C++ better than C, then it's usually good enough.
C is the original performant language, but it turned out to be only marginally easier to maintain than assembler.
C++ was originally intended to make the code easier to maintain, but like all efforts in that direction, the cost was in performance
Then in the early 2000s, it was discovered that there were some really performant things you could do with C++ that didn't hurt the maintainability, and now it is possible to write C++ that is both maintainable and highly performant. The problem is that the cost of this bargain is that there is a very high complexity to the task. Mediocre programmers can still manage to write performant code that is un-maintainable, or slow code that is easily maintainable, but an expert can achieve both.
C is no longer the performance king. A highly skilled C++ programmer can write c++ code that will outperform even the best C code. The cost of that performance is template meta-programming. It's a higher level of abstraction; its bitchy hard to understand; it's 100% necessary for performance; deal with it.
Modern programmers should be required to demonstrate proficiency with template meta programming as a prerequisite to being allowed to practice, much the way a course in lisp is included in virtually every accredited computer science degree.
No. There's a huge difference between learning the proper idioms of a language vs. needing to avoid dangerous, confusing, and hard to use aspects of a language.
Contrary to popular belief, C++ does not have very many aspects that should be avoided. The simple fact is that C++ is a reflection of how complicated high performance computing really is. If you don't understand C++ than you damn sure don't understand writing performant code, and are more than likely a contributing factor to why a computer in 2017 feels no faster than a computer from 2005, in spite of having a processor that is at least 20x faster. Far too many programmers are willing to (or only capable of) write dog-slow code, and release it. If software engineering were held to the same standard as any other engineering discipline, 80% of the "software engineers" out there would be barred from practicing due to incompetence. In what world would we allow someone with a 2 month correspondence course to perform architectural engineering? How about electrical engineering? Or Civil engineering? Ok, maybe Civil Engineering...
Those who complain that C++ is too complicated, do not understand how computers actually work. If they did, they would know why C++ is the way it is, and would know how to use it. They would also know why most other languages should be considered inferior. Instead, they display their own ignorance.
Perhaps, but some of them are still better than others.
And some of them actively prevent you from writing good code.
Maintainability, while important, isn't the only measure of quality code. Performance is equally important and often overlooked. (I'm giving you the evil eye Java)
Need a language for writing enterprise-scale server code? Java.
It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java. Java is a decent language if you have more compute power than you really need, but not enough to run Python. If you are writing enterprise scale code in Java, then you are wasting a lot of compute power. The point of Java was not to make performant code easier to write, but to make code more maintainable. Any competent C++ developer can get you both performant and maintainable code. The secret really is in the template meta-programming. It allows you to do high performance things that simply can't be done in any other language, including C. I can beat the performance of any implementation in Java, using C++, by at least 25%.
A prime example of why I can do that is garbage collection. If you implement a linked list in Java or C++, as each node is created, it will have memory allocated for it from the heap. When you are done with the list, each node must then be freed. With a million nodes, that is a million memory allocations and a million frees. Using custom allocators in C++, I can avoid all of those allocations and frees, and use a single memory pool for all of the objects. This requires extra effort, but fundamentally cannot work with Garbage Collection, so in Java, you simply can't create an implementation that can compete. This is just an example of one of the many ways in which Java ties the developers hands in ways that guarantee sub-optimal performance.
All the things that people complain about being too complicated or "dangerous" in C++ are the very things that give the developers the power to write software that doesn't suck. In all, if a programmer doesn't understand the complexities of C++, then I would argue that they don't understand the complexities of programming for performance, because the first derives directly from the second, and if you fully appreciate programming for performance, then all of the mysteries of C++ will be open to you.
The first hybrid electric car was the Lohner-Porsche, which used lead acid batteries, but I assume you are referring to the Toyota Prius and Honda Insight, which employed NiMH
Sorry, I should have been clearer: the first Lithium hybrid cars had serious issues. The manufacturers thought that the lithium batteries were simple drop in replacements for the NiMH and had them setup to trickle charge with the obvious results.
essentially a resistance heater in an electricity storage device.. for when the natural heat generated from charging isn't 'enough' to keep a suitable temperature?
wow. it took 'til 2018 to come up with that?
Car makers (Tesla not withstanding) are remarkably inept at designing and manufacturing electric systems. They primarily consist of mechanical engineers who think all batteries work like lead acid batteries.
The first hybrid cars that came to market continuously trickle charged the lithium packs, and had absolutely no environmental controls on the packs. This caused the batteries to wear out within 5 years, and caused numerous car fires.
The first all electric car that Nissan produced also had zero battery temperature conditioning, and as such the pack would wear out and have to be replaced after just 60k miles. Nissan has since corrected the problem, but only just barely.
The traditional car manufacturers are bloated and incompetent dinosaurs, and the great recession should have killed half of them were it not for corrupt politicians handing out money like candy to babies.
You don't trickle charge a lithium chemistry battery. This is the #1 cause of lithium battery fires and explosions. To store them for long periods of disuse, you have to charge them to a storage charge (typically 50%) at which point they are good for about 2-3 years of storage. After that, they need to be restored to their storage charge again. Storing Lithium batteries at full charge accelerates internal corrosion (anode gets oxidized iirc), and will reduce the total lifespan of the battery by half or more.
Properly cared for, a lithium chemistry battery will still have 75% of its total capacity after 15 years and 1000 complete charge discharge cycles (or 5000 20% charge cycles) This means keeping them within their proper operating temperature and not charging / discharging them when they are too cold or too hot.
Are you claiming, without evidence, that all of the deaths in Chernobyl were covered up by the USSR? That is a massive conspiracy. There have been cases of thyroid cancer, but that has a very low fatality rate and it is treatable.
Are you a moron? This was literally the first link in a google search for chernobyl deaths.
You can find some good information about the Chernobyl Liquidators. There are thousands of sites, articles, and studies, and god knows how many videos on you-tube from various sources, from the reputable to the downright dishonest. I have watched thousands of hours of related videos on every nuclear accident that I have been able to find. I have read tens of thousands of pages of documents, testimony and explanations. I am as close as you can get to being an expert in nuclear accidents as you can get without having a degree in nuclear engineering. There is no cover up, there are no conspiracies, just most people don't care about the gritty details the way I do. The WHO Estimates that there will be a total of about 4000 premature deaths, but this is a far cry from the Greenpeace estimates of 200,000. Greenpeace is completely bonkers (Think tin-foil hat levels of crazy). The WHO estimate is likely the most accurate estimate, as their methodology is by far the best, but only a head in the sand idiot believes the official death toll is anywhere near as low as 60. Even the soviets didn't try to keep that fiction going long.
Slashdot Mirror
That may be self-interested and greedy, but it is not stupid.
It is in fact stupid. Unchecked, a society that permits that behavior only ends one way, just ask the French aristocracy, or the Russian Tsars.
Ok, I'll have a go:
1: There is nothing intrinsic to crypto that makes it go up. If demand (i.e. utilization) is not growing as fast as new coins are mined, then the value drops. This is even more pronounced when the utilization growth goes negative. See yesterday, and last month, and this whole year. BTC is currently worth less than half what it was last year, and has the potential to drop all the way to zero without major changes to the world we live in. USD by contrast would only be capable of dropping to zero by way of the apocalypse.
2: They are only as secure as the software that is used to handle it. Software in general is notoriously insecure. Also see 51% attack.
3: You can achieve this same effect using a brokerage service, of which there are millions in every flavour you could want. The easiest to use variants are Credit Cards which are accepted almost universally. Visa handles 150M transactions per day, or approximately 3 orders of magnitude more than bitcoin, and in spite of that high load, they handle individual transactions in seconds. Nothing about cryptocurrency is inherently faster, better or safer.
4: Oh Really?
5: Only if they are universally accepted. If people stop accepting them, then they loose utility, and less people will be inclined to use them, which makes them even less useful. This is known as a death spiral, and the research cited in this story seems to indicate that bitcoin is headed in exactly that direction. This phenomenon is not unique to cryptocurrency, and is one of the reasons that AmEx plays dirty pool to force retailers to keep accepting their cards.
By the way, BTC is up 3.5% or so again since yesterday's drop
And now an hour and a half later its back down again.
There are only two institutional users of bitcoin now: Market manipulators and money launderers / tax evaders. Everyone else abandoned that ship, but the money launderers will prop up the price indefinitely because they are both the buyer and the seller. The only way crypto goes to zero is when the money launderers are stopped, and you can bet that tax agencies the world over are working on that problem as we speak.
The collapse wont be an overnight crash, just a long slow slide to oblivion as the launderers are either caught, or figure out that crypto is not anonymous enough to protect them, and fewer and fewer remain.
They randomly changed Mystreet Street to Mystreet Ave. You don't realize the amount of services that rely on Google for address verification until it starts throwing you errors about an invalid address. Fuck you Google, it still says Street on the signs and even on your goddamn streetview images.
If you think thats bad, you should see what happens when the 911 database (yes they keep their own address database based on the US postmaster postal standard) is wrong. At least with google you have some idea of whom to send an e-mail to. With 911, there is literally 1 person in the entire country who has the knowledge, the access and the authority to actually fix that problem for any given location, and good luck finding them. You can't even be sure what state they work in or what agency they work for. The collective group of them don't even know how to contact each other.
Education (and largely healthcare) reflect demographics, not anything about the state per se.
Cough, Cough, Bullshit, Cough
Considering how many S and X motor units they have replaced, the fact that they made the 3 one easy to replace doesn't inspire confidence. How old are the oldest 3s out there now? Maybe they are just being careful, if they had to do mass warranty replacements it would destroy them if it was as much work as the S/X.
The real need is actually much more acute. When a car is manufactured, the vehicle moves through the assembly process having parts installed. The number of steps in this process determines how long the assembly line needs to be. Just like a processor pipeline, when everything goes right, it doesn't matter how long the pipeline/assembly line is, you will still finish cars / instructions at the rate at which the slowest step can be performed.
If something breaks down in the pipeline/ assembly line somewhere, then the length of the line determines the penalty.
What tesla has done by having the entire axle assembly removable is to parallelize the assembly process so that a breakdown in the axle sub-assembly line doesn't impact the overall assembly line progress. Its a smart bit of engineering, and one of the many ways in which they are making cars that cost less to build while having better specs and better overall quality. The shorter the pipeline, the less defects have to be tolerated in order to make production rates.
How's that for a car analogy!
Copyright was invented for the good of society. It was intended to provide some level of protection against the risk of creating original works and in exchange, people would create good works that society would benefit from. The original idea was a balance that provided maximum benefit to society. It has nothing to do with rights, and is the most poorly named concept in our legal/justice system which is saying something. These are privileges that our society chooses to impart on specific individuals and corporations.
What we have now, is a system whereby copyright exists almost exclusively for the profit of a few corporations at the expense of society (That which should be free isn't, and society has no access to these works except to continue paying the Danegeld.) Copyright law is broken. The original benefit to society that was envisioned has not played out, and either balance needs to be restored to the law (7 year terms tops), or the law needs to be eliminated completely as the miserably failed social experiment that it is.
The very idea that they are irrevocable rights is absurd on the face of it, and grants far too much authority to our government in the first place. I would submit that our government should not even have the authority to grant copypriviledge to anyone, and that this ill-gotten power should be stripped from the government at the soonest possible opportunity.
Copyright is government interference in the free markets and is fundamentally at odds with Republican small government and Democratic regulation of business. It is antithetical to every partys stated positions, so why is it perpetuated and made worse by each successive congress?
I want to know which logfile editor to use to read the journal.d or /etc/logs.
That would be journalctl. I don't know what the hot-key combo for emacs is, but you can be relatively sure there is one
For vi or emacs, you could do:
but I'm not sure why you wouldn't just look at the output of journalctl directly. Its output can be piped through your favorite parsing and sorting programs just the same as if it you were directly reading from a file.
If you are talking about writing to the logs, then you should use the existing logging mechanisms in your programming language of choice, they still work the way they always did.
If you are talking about altering existing system logs, then I am going to say with all due rudeness, that you are talking about the Linux equivalent of altering official documents, and are either up to something nefarious, or are a blithering idiot, either way I see no reason to make your task any easier than it has to be.
At the end of the day, this is all about the fact that the world is not text based, it is based in far more complex and subtle data types, and it is time that the Unix/Linux weenies got with the program and dealt with the fact that \0 can and should be used for things other than the end of a string of text.
Around 2014, with the switch to Systemd, Debian started to decline in popularity. This was followed by the equally stunning change in Ubuntu to the same init system. By 2018, it was apparent that both distributions were headed to the scrap heap of history as they had lost nearly 80% of their user base in the 3 intervening years.
Oh, wait, that didn't actually happen? Debian/Ubuntu still has the same userbase in the Linux Desktop and Server markets it had before the Systemd change?
I guess the markets have spoken, and the predictions of doomsday were nothing more than the echo chamber effect of a very small and very vocal minority of people who do not appear to represent either Linux users or Linux developers as a whole. That is the only explanation that fits the facts.
How long an iteration of a loop takes to execute is irrelevant. What matters is the circumstances contributing to iteration count.
The number of iterations in many instances is fixed and cannot be improved. For example when processing the records in a database, you have to iterate over all of the records. Any reasonably sized database will have millions of records. The databases I deal with have trillions of records. Yuo certainly don't want to waste iterations, but thinking that the amount of processing in the record loop is irrelevant is ignorant.
You ivory tower types are all the same.
Ivory tower? My code is routinely profiled against C implementations, and my code routinely wins. I have to know where every cycle goes because I have hard limits on wall clock execution time, and thanks to having actual data security, throwing cloud based resources at the problems to make up for lack of programming skill is not an option.
Using TMP, I can beat even the tightest inner loops written in pure C. I get paid good money to shave milliseconds, and at every step of the way I have to prove conclusively that my solutions are better than what was already there. The kind of work I do is very lucrative, but it weeds out the incompetent at a frightening rate, and there is a damn good reason I am one of the survivors.
Unfortunately, a lot of the developments in C++ within the past decade have been more about fixing what was already there but somewhat broken than breaking new ground.
And yet here we are nearly 20 years later, and no one has a better alternative to TMP, and most languages don't offer anything at all.
But if you master it you'll never run into a roadblock that doesn't have a solution.
Thats what you think...
I want to iterate over an enum where the code in the loop calls a templated function using the enum value as the template argument.
If you can figure out how to do it, let me know.
When coding with assembly, programmers would use macros in the same way templates were used. You would define your macro with parameters defining the local name of each register storing that variable. Then if you wanted to reorder register usage, you just change the order of the parameters in the macro call.
I'm afraid you have not only missed the entire point of templates, but also their most powerful capabilities as well
Templates are for implementing the same function multiple times with variations between them, but without having to rewrite the whole function in every variation you want to implement. For example: (I apologize about the formatting)
template<tbool T_bRounded>
//Do some stuff to find x
void foo()
{
if( T_bRounded)
{
return( round(x));
}
else
{
return(x);
}
}
This simple function implements a call that either returns x, or rounds it first, and then returns it. The magic of the implementation is that the conditional on T_bRounded does not result in an actual jump instruction. Instead, the function is instantiated twice, once with the return in the if clause, and once with the return in the else clause. The correct function is called based on the template parameter that is used. For this simple example, it is not terribly useful, but imagine that foo has an inner loop where T_bRounded gates a particular behavior that is executed millions or billions of times. Not having that extra conditional jump in the assembled code will make a huge difference to the resulting compute time. That is a simple example of the real power of TMP. Imagine if you have a dozen such booleans that you want to gate out various behaviors from an inner loop. You could easily double or triple the speed of the inner loop. The only way to write competing code in C would be to write 4096 versions of the function with all possible combinations of the twelve flags, and call the correct one based on the flags using a jump table. What are the odds that you could write all 4096 without having a significant number of mistakes? With TMP, you write it once and the compiler spreads it out for you.
So yes, in my opinion if a language makes it too easy to write horrible code and very challenging to write great code it is probably a horrible language.
Think about it a little differently: There are a few primary goals when writing code. The first is speed of coding: how fast can the developers get the work done. The second is maintainability: How easy will it be to get new developers up to speed on the project, and how easy will it be for them to add new features. The Third is code performance.
Some languages address the first item very well. Python is a good example of a language that allows you to get something working very quickly. It can be maintainable or not depending largely on the quality of the code that is written and the presence (or lack) of comments. Python simply cannot be performant. It is an interpreted language, but even compiled, it cannot achieve high performance because it lacks the language constructs necessary to permit high performance computing.
Some languages address the second very well. Java was designed to be a language that follows a rigid pattern of development that should be very similar across projects. In theory this should allow a developer to come up to speed more quickly because there is only one way to do each thing that needs to be done. In practice, Java developers can write horrrendous code too, and for the similar reasons to Python, Java simply cannot be performant.
For the third, there are very limited options for raw performance. They really are: Assembler, C++ and C, in descending order of absolute performance (C++ might even edge out assembler now thanks to TMP. In theory you could implement the same thing in assembler, but good luck). Developers can write maintainable code in any of the three, or they can write junk. It really depends on the developer.
At the end of the day, the first two priorities can be had in any language depending on the skill of the developer, but the third priority can only be had in those three languages. It is due in no small part to those capabilities that C++ is as complicated as it is. It can do things that *no other language can do*.
In the end, if there is even the slightest possibility that performance will be a project priority, then you are limited to C, C++ or Assembler.
If one uses every single feature of C++, then it's probably a really terrible language.
If one only uses features that make C++ better than C, then it's usually good enough.
C is the original performant language, but it turned out to be only marginally easier to maintain than assembler.
C++ was originally intended to make the code easier to maintain, but like all efforts in that direction, the cost was in performance
Then in the early 2000s, it was discovered that there were some really performant things you could do with C++ that didn't hurt the maintainability, and now it is possible to write C++ that is both maintainable and highly performant. The problem is that the cost of this bargain is that there is a very high complexity to the task. Mediocre programmers can still manage to write performant code that is un-maintainable, or slow code that is easily maintainable, but an expert can achieve both.
C is no longer the performance king. A highly skilled C++ programmer can write c++ code that will outperform even the best C code. The cost of that performance is template meta-programming. It's a higher level of abstraction; its bitchy hard to understand; it's 100% necessary for performance; deal with it.
Modern programmers should be required to demonstrate proficiency with template meta programming as a prerequisite to being allowed to practice, much the way a course in lisp is included in virtually every accredited computer science degree.
No. There's a huge difference between learning the proper idioms of a language vs. needing to avoid dangerous, confusing, and hard to use aspects of a language.
Contrary to popular belief, C++ does not have very many aspects that should be avoided. The simple fact is that C++ is a reflection of how complicated high performance computing really is. If you don't understand C++ than you damn sure don't understand writing performant code, and are more than likely a contributing factor to why a computer in 2017 feels no faster than a computer from 2005, in spite of having a processor that is at least 20x faster. Far too many programmers are willing to (or only capable of) write dog-slow code, and release it. If software engineering were held to the same standard as any other engineering discipline, 80% of the "software engineers" out there would be barred from practicing due to incompetence. In what world would we allow someone with a 2 month correspondence course to perform architectural engineering? How about electrical engineering? Or Civil engineering? Ok, maybe Civil Engineering...
Those who complain that C++ is too complicated, do not understand how computers actually work. If they did, they would know why C++ is the way it is, and would know how to use it. They would also know why most other languages should be considered inferior. Instead, they display their own ignorance.
Perhaps, but some of them are still better than others.
And some of them actively prevent you from writing good code.
Maintainability, while important, isn't the only measure of quality code. Performance is equally important and often overlooked. (I'm giving you the evil eye Java)
Need a language for writing enterprise-scale server code? Java.
It's funny that you expressed the opinion that people should not write fullstack purely in Javascript, but were OK with writing enterprise scale software in Java. Java is a decent language if you have more compute power than you really need, but not enough to run Python. If you are writing enterprise scale code in Java, then you are wasting a lot of compute power. The point of Java was not to make performant code easier to write, but to make code more maintainable. Any competent C++ developer can get you both performant and maintainable code. The secret really is in the template meta-programming. It allows you to do high performance things that simply can't be done in any other language, including C. I can beat the performance of any implementation in Java, using C++, by at least 25%.
A prime example of why I can do that is garbage collection. If you implement a linked list in Java or C++, as each node is created, it will have memory allocated for it from the heap. When you are done with the list, each node must then be freed. With a million nodes, that is a million memory allocations and a million frees. Using custom allocators in C++, I can avoid all of those allocations and frees, and use a single memory pool for all of the objects. This requires extra effort, but fundamentally cannot work with Garbage Collection, so in Java, you simply can't create an implementation that can compete. This is just an example of one of the many ways in which Java ties the developers hands in ways that guarantee sub-optimal performance.
All the things that people complain about being too complicated or "dangerous" in C++ are the very things that give the developers the power to write software that doesn't suck. In all, if a programmer doesn't understand the complexities of C++, then I would argue that they don't understand the complexities of programming for performance, because the first derives directly from the second, and if you fully appreciate programming for performance, then all of the mysteries of C++ will be open to you.
But it's not what you shove up your ass. That's what your iPhone is for.
I saw that App, but I didn't want to shell out 5 bucks for the ad-free version...
Windows XP/2003 was the high water mark for Windows. It has been steadily downhill since.
Ubuntu 16.04 is the high water mark for Windows...
Those who know use Debian or BSD. Those that don't use Ubuntu
Those that will happily send a check to the prince of Nigeria use Windows.
The first hybrid electric car was the Lohner-Porsche, which used lead acid batteries, but I assume you are referring to the Toyota Prius and Honda Insight, which employed NiMH
Sorry, I should have been clearer: the first Lithium hybrid cars had serious issues. The manufacturers thought that the lithium batteries were simple drop in replacements for the NiMH and had them setup to trickle charge with the obvious results.
essentially a resistance heater in an electricity storage device.. for when the natural heat generated from charging isn't 'enough' to keep a suitable temperature? wow. it took 'til 2018 to come up with that?
Car makers (Tesla not withstanding) are remarkably inept at designing and manufacturing electric systems. They primarily consist of mechanical engineers who think all batteries work like lead acid batteries.
The first hybrid cars that came to market continuously trickle charged the lithium packs, and had absolutely no environmental controls on the packs. This caused the batteries to wear out within 5 years, and caused numerous car fires.
The first all electric car that Nissan produced also had zero battery temperature conditioning, and as such the pack would wear out and have to be replaced after just 60k miles. Nissan has since corrected the problem, but only just barely.
The traditional car manufacturers are bloated and incompetent dinosaurs, and the great recession should have killed half of them were it not for corrupt politicians handing out money like candy to babies.
OR park it for 12.5 years on a trickle charger
You don't trickle charge a lithium chemistry battery. This is the #1 cause of lithium battery fires and explosions. To store them for long periods of disuse, you have to charge them to a storage charge (typically 50%) at which point they are good for about 2-3 years of storage. After that, they need to be restored to their storage charge again. Storing Lithium batteries at full charge accelerates internal corrosion (anode gets oxidized iirc), and will reduce the total lifespan of the battery by half or more.
Properly cared for, a lithium chemistry battery will still have 75% of its total capacity after 15 years and 1000 complete charge discharge cycles (or 5000 20% charge cycles) This means keeping them within their proper operating temperature and not charging / discharging them when they are too cold or too hot.
Are you claiming, without evidence, that all of the deaths in Chernobyl were covered up by the USSR? That is a massive conspiracy. There have been cases of thyroid cancer, but that has a very low fatality rate and it is treatable.
Are you a moron? This was literally the first link in a google search for chernobyl deaths.
You can find some good information about the Chernobyl Liquidators. There are thousands of sites, articles, and studies, and god knows how many videos on you-tube from various sources, from the reputable to the downright dishonest. I have watched thousands of hours of related videos on every nuclear accident that I have been able to find. I have read tens of thousands of pages of documents, testimony and explanations. I am as close as you can get to being an expert in nuclear accidents as you can get without having a degree in nuclear engineering. There is no cover up, there are no conspiracies, just most people don't care about the gritty details the way I do. The WHO Estimates that there will be a total of about 4000 premature deaths, but this is a far cry from the Greenpeace estimates of 200,000. Greenpeace is completely bonkers (Think tin-foil hat levels of crazy). The WHO estimate is likely the most accurate estimate, as their methodology is by far the best, but only a head in the sand idiot believes the official death toll is anywhere near as low as 60. Even the soviets didn't try to keep that fiction going long.