Barges have to be flat bottomed, though I'm guessing this thing may be flat bottomed. Barges can also have their own propulsion...
So far I've check Wikipedia, the Free Dictionary and Merriam Webster (sorry if those last two cover the American Language rather than English). They all agree a barge may be powered, but they disagree on whether it has to be flat bottomed or just usually is.
the river homes that people pilot around the canals here in the UK are barges
In the US they're called houseboats, but British usage still jibes (albeit grandiosely) with definitions of barge other than "big ugly thing for cargo".
b : a large motorboat supplied to the flag officer of a flagship c : a roomy pleasure boat; especially : a boat of state elegantly furnished and decorated
I think the negative income tax is a better approach.... Lamentably, I think the chance of this happening is very small.
Lament no more - we already have it. It's called the Earned Income Tax Credit. Perhaps we should expand it, but we do already have it. It was actually the brain child of Milton Friedman, and was promoted by the right wing as superior to welfare (a sentiment you apparently agree with).
I would like particular sources that it did not "systematically lower standards of living"
See here.. Even the pessimists think that there was only a very slight decline in the standard of living in the earlier stages of the industrial revolution, while the optimists think there was a moderate increase. Even more telling is the following from that source:
The standard-of-living debate today is not about whether the industrial revolution made people better off, but about when. The pessimists claim no marked improvement in standards of living until the 1840s or 1850s. Most optimists, by contrast, believe that living standards were rising by the 1810s or 1820s, or even earlier.
In other words, the disagreements between economic historians cover only a small range. No one believes that those evil machines turned the average Briton from a happy prosperous person into a poverty stricken wretch. They'd been poverty stricken wretches for centuries. Were it not for the industrial revolution, they'd still be that way.
If you mean that it didn't lower the mean standard of living...well, that's what you expect if you take the lower end of the economic curve and truncate it. So that, again, is not a contradiction. People who died aren't counted.... In a way, it's like a plague. The survivors of the plague are wealthier than they were before, because in many cases those who owned property are no longer there to claim it. But this does not imply that it's wrong to fear the plague. You don't know that you, and those you care for, will be a survivor.
British life expectancy rose consistently starting in the mid 18th century which, coincidentally or not, was about the beginning of the First Industrial Revolution (typically dated 1760). The increase in life expectancy continued throughout the 19th century.
The sky did fall. The protestors of the 1800's were correct. The people displaced by technology in the 1800s fell into poverty and early death, and England, for instance, was home to immense poverty and despair.
You're repeating a common myth about the First Industrial Revolution. Here is a description of the actual changes in standard of living of most Britons (bottom 65%) during that era. There is some debate, but even the pessimists talk about only a very small decline in standard of living. There is much evidence for the optimists view that there was a modest increase. No economic historian thinks that there was the sort of dramatic decline you describe.
A decade, huh? That means many of the compilers intended for embedded work should get the feature in 5-10 years.
Mostly I work w/ DSP, but often have a mix of DSP and "regular" code. The compilers tend to be very good in terms of optimization where it counts most in that work - loops, arithmetic, etc. They even do a good job w/ optimization that uses specialized architectural features that are common in such processors. The compilers are had to beat even w/ assy. When it comes to keeping up with standards and tricks like this (like I said, people are used to turning off exceptions for deeply embedded stuff) they're pathetic.
Self-driving cars, now robotics more generally? Maybe this sort of exploration is the right thing to do when you've got so much cash. It sure as hell beats those companies that have stopped investing in R&D, but considering how disparate this stuff is from search engines and whatnot, it does strike me as being a bit of a dilettante.
It's not long. And I don't think people will be ready to cope with the change. They haven't thought about what a tool which completely replaces a human and which costs less than a human salary means.
Didn't we have the same problem when those newfangled automated spinning and weaving machines replaced handwork? Or is the singularity just around the corner? I guess it must be, since it's always been just around the corner.
Ok, maybe I'm being overly sarcastic, but this does seem like a "sky is falling" issue. I don't think we know what will happen. Predictions are hard to make - especially about the future.
Dereference errant or even NULL pointers, exceed array bounds, foot loose and fancy free type conversions, I'm sure you've heard these and more. If you really like to write code without the safety net, use assembly language (I sometimes do). As for making "coders sloppier", I find that's true of all these newfangled HLL's. I'm never more careful or more disciplined than when writing assembler.
I know how to avoid the dangers of C, and dare say I'm pretty good at it. I rarely make a mistake, but rarely isn't never. Also sometimes I work with other programmers that frankly aren't as good at avoiding the dangers. Makes integration fun. The situation is even more fun when security is a major concern (it generally isn't for what I do).
Some may make some dangers more implicit
What does that mean and what's an example? No snark - I honestly don't understand the point.
Well a lot of programmers seem to use exceptions for normal/common flow control.
When I first learned about exceptions, they came with the strong advice not to use them for normal flow control. Naturally I had to try it for myself, and quickly learned that was excellent advice. No language is idiot proof.
Nice! I hope it sees widespread use there because, like I said, that may be about the only way the language will really catch on. Right now I get the feeling a lot of people either don't know or don't care about the language, because I every time I mention it here there's almost no reaction. A flame war would be better than ignoring it.
BTW, I've only recently started using it, although I've known about it for years. From what I understand, up until fairly recently, it had some rough edges. They seem to have been polished D2 has completely superseded D1, the old Phobos vs. Tango library issue is gone (only Phobos now - Tango is thankfully dead).
The one thing that seems to still need some polish is the GC implementation. Right now they have a "stop the world" GC, but someone is porting the Boehm GC. Currently alpha, but looks good.
The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by.
Ditto. It's just that it's always a sore point with me when an inferior design wins out for silly reasons, especially when I have to live with the inferior product. But it's hardly important enough for me to spend the rest of my life decrying the injustice of Git winning over Hg (10 or 20 years of ranting should suffice).
I wanted to start a flame war for fun, but you're throwing rocket fuel on the fire. Using that four letter word practically guarantees a conflagration.
If these features are an impediment, Java isn't the best platform to be using.
Basically that's saying it's not very flexible. There are languages that are safe by default, but allow you to do "unsafe" things where necessary, and make it very clear that something unsafe is being done (requires an "unsafe" pragma or something). If a given project shouldn't need any unsafe code, you can easily ensure that it doesn't.
I believe the old way was to add stuff to the stack frame in order to track things. This obviously added overhead. The new way was to build a lookup system that takes the PC and uses that to jump into the unwind code. I think the lookup of the PC is quite slow, but it does not add any cost on the hot path.
Nice approach. Who cares how long it takes once you've thrown an exception?
In terms of embedded code... yeah dunno.
Ideally what I'd like is to have the lowest, most speed critical code, not throw exceptions or incur any overhead due to their existence. I know that a function that doesn't throw any exceptions itself still has to have some provision for dealing with exceptions, but suppose you could guarantee that function foo() throws no exceptions and that none of the functions it calls do. Would a nothrow decl for foo(), and no catch statement in foo(), guarantee that? Would the compiler be smart enough to figure it out and take advantage of it?
Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.
I am not so sure about that. At least, it still is a quite viable platform. You can learn the language and do useful stuff with it, including GUI apps, and you can distribute them without problems. Many of the libs are quite up-to-date.
But who uses it for anything other than legacy code? Even the DoD dropped their mandate 16 years ago. F-22 software is written in Ada, but F-35 software in C++ (remind me to find deep shelter if I'm ever near an F-35 base).
Old languages (even if they've been updated like Ada) that never really caught by a certain point almost always die, even if very slowly. A newer language has a better chance. It's more of a sociological issue than a technical one, but that doesn't alter the reality of it.
Anyway, why did you have to be careful admitting you liked Ada?
Because sometimes my Nomex underwear was in the wash. Back when people had heard of it, any mention of Ada brought all sorts of ignorant criticism and flaming. Eventually I got tired of the argument. I knew I was right, and to hell with anyone who didn't realize it:)
I really don't see the need to use any language other than C. It is simple, elegant, straightforward, portable and versatile, it allows you to do everything you need without too much cargo cult and there is an enormous number of tools available.
Similarly I think that these newfangled "word processors" or even text editors are ridiculous. What can't you do with pencil and paper?
I use C daily for deeply embedded stuff (no OS, ultra-low latency, etc.) and it's still the best choice for that and similar work (e.g. kernels). Sometimes I even use assembly language. But for 20 years now C has been an inappropriate language for "general purpose" applications (i.e. don't talk directly to hardware, etc.). It's too primitive and needlessly dangerous. C was originally created as a systems implementation language, and became popular for other stuff on Unix mostly because the compiler was there, and back in the day when tweaking your Unix box meant modifying the source code, everybody knew it.
I don't like mixed language programming myself, but you may have limited control over. it. Even if you write everything in language X, important off-the-shelf libraries and whatnot may be implemented in language Y.
Java refuses to provide unsafe primitives in the Java language itself
They're trying to save you from yourself, or from the most inept programmer you have. Sorry folks, there is no such thing as an idiot proof language. A simple and effective approach, which other languages use, is to have anything that's unsafe include "unsafe" in their name. Then you can find where it's used with a simple text search (or is that too simple for a modern IDE?).
One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.
I've heard that before and am seriously interested in 2 questions:
1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.
2. Any benchmarks, cites, whatever?
#2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas) and the standard rule for years has been to turn off exceptions. Many compilers for embedded work even do that by default. I'd love to be able to change that, since exceptions make error handling so much easier.
Just thought of something else: even if modern compilers have improved, it's far from a guarantee that ones for embedded use have. At least gcc should though, and that's used for some embedded work.
There's a difference between needing an IDE and simply preferring one. With other languages I like a good IDE, but I've worked on large projects without one, and it's not terribly painful. With a Java project beyond trivial size it feels like you just can't function without an IDE. That's bad language design.
Slashdot Mirror
Barges have to be flat bottomed, though I'm guessing this thing may be flat bottomed. Barges can also have their own propulsion ...
So far I've check Wikipedia, the Free Dictionary and Merriam Webster (sorry if those last two cover the American Language rather than English). They all agree a barge may be powered, but they disagree on whether it has to be flat bottomed or just usually is.
the river homes that people pilot around the canals here in the UK are barges
In the US they're called houseboats, but British usage still jibes (albeit grandiosely) with definitions of barge other than "big ugly thing for cargo".
b : a large motorboat supplied to the flag officer of a flagship
c : a roomy pleasure boat; especially : a boat of state elegantly furnished and decorated
Ok, argue it.
If all the poor are dead, who will fix the robots?
Other robots.
I think the negative income tax is a better approach. ... Lamentably, I think the chance of this happening is very small.
Lament no more - we already have it. It's called the Earned Income Tax Credit. Perhaps we should expand it, but we do already have it. It was actually the brain child of Milton Friedman, and was promoted by the right wing as superior to welfare (a sentiment you apparently agree with).
I would like particular sources that it did not "systematically lower standards of living"
See here.. Even the pessimists think that there was only a very slight decline in the standard of living in the earlier stages of the industrial revolution, while the optimists think there was a moderate increase. Even more telling is the following from that source:
The standard-of-living debate today is not about whether the industrial revolution made people better off, but about when. The pessimists claim no marked improvement in standards of living until the 1840s or 1850s. Most optimists, by contrast, believe that living standards were rising by the 1810s or 1820s, or even earlier.
In other words, the disagreements between economic historians cover only a small range. No one believes that those evil machines turned the average Briton from a happy prosperous person into a poverty stricken wretch. They'd been poverty stricken wretches for centuries. Were it not for the industrial revolution, they'd still be that way.
If you mean that it didn't lower the mean standard of living...well, that's what you expect if you take the lower end of the economic curve and truncate it. So that, again, is not a contradiction. People who died aren't counted. ... In a way, it's like a plague. The survivors of the plague are wealthier than they were before, because in many cases those who owned property are no longer there to claim it. But this does not imply that it's wrong to fear the plague. You don't know that you, and those you care for, will be a survivor.
British life expectancy rose consistently starting in the mid 18th century which, coincidentally or not, was about the beginning of the First Industrial Revolution (typically dated 1760). The increase in life expectancy continued throughout the 19th century.
The sky did fall. The protestors of the 1800's were correct. The people displaced by technology in the 1800s fell into poverty and early death, and England, for instance, was home to immense poverty and despair.
You're repeating a common myth about the First Industrial Revolution. Here is a description of the actual changes in standard of living of most Britons (bottom 65%) during that era. There is some debate, but even the pessimists talk about only a very small decline in standard of living. There is much evidence for the optimists view that there was a modest increase. No economic historian thinks that there was the sort of dramatic decline you describe.
You should get all your programmers from Glasgow.
Glaswegian programmers all use Haskell.
A decade, huh? That means many of the compilers intended for embedded work should get the feature in 5-10 years.
Mostly I work w/ DSP, but often have a mix of DSP and "regular" code. The compilers tend to be very good in terms of optimization where it counts most in that work - loops, arithmetic, etc. They even do a good job w/ optimization that uses specialized architectural features that are common in such processors. The compilers are had to beat even w/ assy. When it comes to keeping up with standards and tricks like this (like I said, people are used to turning off exceptions for deeply embedded stuff) they're pathetic.
Self-driving cars, now robotics more generally? Maybe this sort of exploration is the right thing to do when you've got so much cash. It sure as hell beats those companies that have stopped investing in R&D, but considering how disparate this stuff is from search engines and whatnot, it does strike me as being a bit of a dilettante.
It's not long. And I don't think people will be ready to cope with the change.
They haven't thought about what a tool which completely replaces a human and which costs less than a human salary means.
Didn't we have the same problem when those newfangled automated spinning and weaving machines replaced handwork? Or is the singularity just around the corner? I guess it must be, since it's always been just around the corner.
Ok, maybe I'm being overly sarcastic, but this does seem like a "sky is falling" issue. I don't think we know what will happen. Predictions are hard to make - especially about the future.
What is so dangerous about C?
Dereference errant or even NULL pointers, exceed array bounds, foot loose and fancy free type conversions, I'm sure you've heard these and more. If you really like to write code without the safety net, use assembly language (I sometimes do). As for making "coders sloppier", I find that's true of all these newfangled HLL's. I'm never more careful or more disciplined than when writing assembler.
I know how to avoid the dangers of C, and dare say I'm pretty good at it. I rarely make a mistake, but rarely isn't never. Also sometimes I work with other programmers that frankly aren't as good at avoiding the dangers. Makes integration fun. The situation is even more fun when security is a major concern (it generally isn't for what I do).
Some may make some dangers more implicit
What does that mean and what's an example? No snark - I honestly don't understand the point.
Well a lot of programmers seem to use exceptions for normal/common flow control.
When I first learned about exceptions, they came with the strong advice not to use them for normal flow control. Naturally I had to try it for myself, and quickly learned that was excellent advice. No language is idiot proof.
Nice! I hope it sees widespread use there because, like I said, that may be about the only way the language will really catch on. Right now I get the feeling a lot of people either don't know or don't care about the language, because I every time I mention it here there's almost no reaction. A flame war would be better than ignoring it.
BTW, I've only recently started using it, although I've known about it for years. From what I understand, up until fairly recently, it had some rough edges. They seem to have been polished D2 has completely superseded D1, the old Phobos vs. Tango library issue is gone (only Phobos now - Tango is thankfully dead).
The one thing that seems to still need some polish is the GC implementation. Right now they have a "stop the world" GC, but someone is porting the Boehm GC. Currently alpha, but looks good.
The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by.
Ditto. It's just that it's always a sore point with me when an inferior design wins out for silly reasons, especially when I have to live with the inferior product. But it's hardly important enough for me to spend the rest of my life decrying the injustice of Git winning over Hg (10 or 20 years of ranting should suffice).
Same reason lisp ultimately never catches on.
I wanted to start a flame war for fun, but you're throwing rocket fuel on the fire. Using that four letter word practically guarantees a conflagration.
If these features are an impediment, Java isn't the best platform to be using.
Basically that's saying it's not very flexible. There are languages that are safe by default, but allow you to do "unsafe" things where necessary, and make it very clear that something unsafe is being done (requires an "unsafe" pragma or something). If a given project shouldn't need any unsafe code, you can easily ensure that it doesn't.
I believe the old way was to add stuff to the stack frame in order to track things. This obviously added overhead. The new way was to build a lookup system that takes the PC and uses that to jump into the unwind code. I think the lookup of the PC is quite slow, but it does not add any cost on the hot path.
Nice approach. Who cares how long it takes once you've thrown an exception?
In terms of embedded code... yeah dunno.
Ideally what I'd like is to have the lowest, most speed critical code, not throw exceptions or incur any overhead due to their existence. I know that a function that doesn't throw any exceptions itself still has to have some provision for dealing with exceptions, but suppose you could guarantee that function foo() throws no exceptions and that none of the functions it calls do. Would a nothrow decl for foo(), and no catch statement in foo(), guarantee that? Would the compiler be smart enough to figure it out and take advantage of it?
And the English language suffices for bad puns (though I understand Mandarin is even better).
Verilog won the popularity contest
Does that make it a better language?
Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.
I am not so sure about that. At least, it still is a quite viable platform. You can learn the language and do useful stuff with it, including GUI apps, and you can distribute them without problems. Many of the libs are quite up-to-date.
But who uses it for anything other than legacy code? Even the DoD dropped their mandate 16 years ago. F-22 software is written in Ada, but F-35 software in C++ (remind me to find deep shelter if I'm ever near an F-35 base).
Old languages (even if they've been updated like Ada) that never really caught by a certain point almost always die, even if very slowly. A newer language has a better chance. It's more of a sociological issue than a technical one, but that doesn't alter the reality of it.
Anyway, why did you have to be careful admitting you liked Ada?
Because sometimes my Nomex underwear was in the wash. Back when people had heard of it, any mention of Ada brought all sorts of ignorant criticism and flaming. Eventually I got tired of the argument. I knew I was right, and to hell with anyone who didn't realize it :)
I really don't see the need to use any language other than C. It is simple, elegant, straightforward, portable and versatile, it allows you to do everything you need without too much cargo cult and there is an enormous number of tools available.
Similarly I think that these newfangled "word processors" or even text editors are ridiculous. What can't you do with pencil and paper?
I use C daily for deeply embedded stuff (no OS, ultra-low latency, etc.) and it's still the best choice for that and similar work (e.g. kernels). Sometimes I even use assembly language. But for 20 years now C has been an inappropriate language for "general purpose" applications (i.e. don't talk directly to hardware, etc.). It's too primitive and needlessly dangerous. C was originally created as a systems implementation language, and became popular for other stuff on Unix mostly because the compiler was there, and back in the day when tweaking your Unix box meant modifying the source code, everybody knew it.
I don't like mixed language programming myself, but you may have limited control over. it. Even if you write everything in language X, important off-the-shelf libraries and whatnot may be implemented in language Y.
Java refuses to provide unsafe primitives in the Java language itself
They're trying to save you from yourself, or from the most inept programmer you have. Sorry folks, there is no such thing as an idiot proof language. A simple and effective approach, which other languages use, is to have anything that's unsafe include "unsafe" in their name. Then you can find where it's used with a simple text search (or is that too simple for a modern IDE?).
One of the biggest parts of the runtime (exceptions) have gone from slow and painful to essentially zero cost if you never use them.
I've heard that before and am seriously interested in 2 questions:
1. What changed to make exceptions efficient? I know it's a a compiler issue, but if anyone is knowledgeable about the details or has a link, I'd be very interested.
2. Any benchmarks, cites, whatever?
#2 is not about skepticism, but being able to shove documentation under someone else's nose. I do a lot of "deeply" embedded stuff (no OS - RTOS or even bare metal, extremely low latency requirements, extremely performance critical in some areas) and the standard rule for years has been to turn off exceptions. Many compilers for embedded work even do that by default. I'd love to be able to change that, since exceptions make error handling so much easier.
Just thought of something else: even if modern compilers have improved, it's far from a guarantee that ones for embedded use have. At least gcc should though, and that's used for some embedded work.
There's a difference between needing an IDE and simply preferring one. With other languages I like a good IDE, but I've worked on large projects without one, and it's not terribly painful. With a Java project beyond trivial size it feels like you just can't function without an IDE. That's bad language design.