There's also differences between what languages do. Programming in Pascal requires a much different mindset than programming in Prolog. It takes time to learn how to write good OO programs, the same for functional programs. Different languages have different gotchas (C++ in particular has a lot of them).
I'd think COBOL would come in high on the "unique lines of code" metric. There's lots of it out there, and it's such an unexpressive language that it needs a lot more lines of code to do things.
Different languages also require different ways of thinking to use them correctly, and C++ is just plain hard to learn well. Functional languages require a different mindset from procedural languages.
C++ has a useful std::map type, with an interface containing functions like begin, end and clear. Other parts of the programming world are taking nested maps, picking out a subset of the top-level map according to some predicate based on the key, value or both of each entry, flattening the structure a level, and then doing a deep merge of another similarly structured nested map with explicit rules for resolving any intersections, and again they're often doing this kind of thing with just a few short lines of code and with the basic patterns provided either via the standard library or directly via built-in language features.
Why do you think any of this is difficult in C++? Nested maps are easy. remove_if is pretty easy, particularly with lambdas, and it's in the standard library. Flattening the structure looks pretty easy, unless I'm missing something. Just loop over the higher-level and lower-level maps, combine the keys as you like, and put them where you want. I'd have to think a few minutes about the deep merge, and have some specifics.
In Haskell, you get tools like mapAccumWithKey, which represents visiting each key-value pair in a map in ascending order of keys, transforming each value according to some rule, and accumulating some state along the way, which may also be used to influence later transformations and/or state updates. Obviously one of these captures a much more specific and powerful pattern than the other.
Visiting each key-value pair in a map and transforming each value according to some rule is easy in C++. (for (auto & p : my_map) p.second = foo(p.second); or something like that) Adding the accumulation would be done in foo or whatever lambda is used, but it's not difficult.
Making a full functional language would be more difficult, but I just don't see how Haskell, or any other programming language, can be that much easier than C++ for a lot of the examples you've given.
It also seems to me it would be significantly more difficult to do in C, which is why I consider C++ much more expressive than C.
I get the impression that you aren't familiar enough with C++ to appreciate its flexibility and expressiveness, much as I'd have a lot of trouble expressing common C++ stuff in Haskell.
If you need performance, it is likely you have a bad algorithm, or are misusing the language, like not using a string builder.
Or you're in one of those problem areas where the fastest known algorithms are slow even when properly coded. The software I'm working on is well maintained and we're always willing to entertain new algorithms. Our code quality is too high. Our code is too slow and everybody would like it to be faster.
C++ isn't C with Classes any more, and hasn't been for decades. C++ has all sorts of tools you can use as you see fit. If OO doesn't fit your problem, don't use it.
Why do you think it's hard to write really efficient C++? I haven't noticed it being any harder than in C, assuming equal functionality.
Remember: if there is an unusually warm few days or weeks, it's because weather and climate are linked.
Nope. A few weeks proves nothing about climate. When the weather changes consistently, and things happen fairly frequently over a period of years that almost never happened before, that's climate.
It almost never rained in winter when I was a kid. Now that I'm older and in the same city, we've had fairly frequent rain in winter for quite a few years now. That's probably climate change, but of course says very little about global warming.
In this case, something happened that had been considered almost completely impossible. One characteristic of climate change is that extreme events move from the nearly impossible to the highly improbable, so one unbelievable event happening does provide evidence.
With the Swedish extradition request, the UK could not have legally extradited Assange to the US. He was safer from the US because of the extradition request.
Assange voluntarily traveled to Sweden, and then to the UK. Going to the UK is a very strange thing to do for someone who fears a US extradition request.
I don't understand the Swedish justice system in any detail, and I distrust accounts from people who aren't authorities and don't cite sources. Trials in absentia are abominations. I see no inconsistency in Sweden's waiting until they can get custody of a suspect to proceed with a case.
Every so often, rape victims call for charges to be dropped, for various reasons. That doesn't mean innocence.
I'm not taking any position on the accuracy of the statements, but one woman accused Assange of holding her down, forcibly removing her clothing, and refusing to wear a condom. Another accused Assange of sex without a condom while she was sleeping. Both of these would be considered felonies whee I live.
C and C++ are subject to errors even the best coders have difficulty avoiding...
C++ is subject to a lot fewer errors than C, although there are some. C++ memory management is generally fairly painless (although you have to pay some attention to detail) until you get a circular shared_ptr list. Even that just leaks memory rather than corrupting anything.
In other words, you're working in a post-Brooks environment, incorporating a lot of ideas that were first widely disseminated in the software field by Brooks.
There's a lot of the book that's irrelevant, nowadays, either common knowledge or (in the light of later knowledge) wrong or dependent on technological limitations nobody has anymore. There's also things that people just don't seem to have learned.
My experience is that decomposition is not a silver bullet. Things never break down as cleanly as you'd like, and there will be things you misestimated or overlooked at the start, and surprises where the intended approach isn't going to work.
Brooks was overstating Brooks' Law, but he appears to have been going for impact rather than precision.
When I'm on a road trip, it's almost always with my wife or some friends. I don't live such a sad and pathetic life that I have to drive hundreds of miles by myself.
It's not so much that vehicles are standing still on the way north, although I've seen that happen, as that there's lots of them. If even a small percentage were low on charge, for whatever reason, the lines for chargers would be pretty long.
I may well have been overgeneralizing from one example, but we used to go on road trips almost immediately on getting home. Throw stuff into the back and go. Leave the interstate after about an hour and spend the next three and a half on increasingly insignificant roads.
The Keynesian method, which nobody seems to practice, is to have some austerity going in good times and forget about it in bad. Too many countries seem to forget about trying to save in good times (the Clinton administration is an exception). Austerity in bad times generally makes them worse. It's cost the Greek economy dearly.
One is finding something that looks promising. Some of this is done by Big Pharma, but a lot is publicly subsidized. It's not necessarily that expensive, so we can profitably keep a lot of labs working on it.
The second is turning something that looks promising into an actual drug that can be used on humans. That's really expensive. It may be necessary to make a lot of molecular changes to the drug, and it may never turn into something significantly deadlier to bacteria than people. Each attempt requires a lot of scarce resources, and I'm happier with numerous people deciding which to pursue rather than having drug research collapse if one authority screws up bad. Having the market decide which avenues to pursue works as long as the profit motive aligns with what we need. If it doesn't, we can make it work. There's a lot of conditions that affect only enough people for FDA-required testing, so, once a drug were released for sale, nobody would buy it. We have some government programs to provide artificial profit for such orphan drugs.
It may surprise you, but the FDA only has authority in the US, and there are in fact civilized areas outside the US. Some of them have their own big pharma companies and everything!
While Western Europe and Japan do better with public health than we do, it's not miraculously better.
Aside from the fact that you have no sense of humor, antibiotic-resistant infections are often curable. People got sick and got well before antibiotics, and they still get sick and well with viruses.
Apple discontinuing product support for a company they bought has lots of possible reasons, and has nothing to do with Apple's motivation for pairing the fingerprint scanner.
Once upon a time, nobody had any security on their iPhones. The PIN was seen as too much work. The fingerprint sensor (which can be disabled if you like) was put there to get people to have some security without inconveniencing them too much.
I took a look at the repair guide for my boiler in the basement. I can't understand it, and if I did I would still not have the tools and measurement devices.
Slashdot Mirror
C# and Java are very similar. Try Scheme and C, or Forth and almost anything.
There's also differences between what languages do. Programming in Pascal requires a much different mindset than programming in Prolog. It takes time to learn how to write good OO programs, the same for functional programs. Different languages have different gotchas (C++ in particular has a lot of them).
I'd think COBOL would come in high on the "unique lines of code" metric. There's lots of it out there, and it's such an unexpressive language that it needs a lot more lines of code to do things.
Different languages also require different ways of thinking to use them correctly, and C++ is just plain hard to learn well. Functional languages require a different mindset from procedural languages.
Why do you think any of this is difficult in C++? Nested maps are easy. remove_if is pretty easy, particularly with lambdas, and it's in the standard library. Flattening the structure looks pretty easy, unless I'm missing something. Just loop over the higher-level and lower-level maps, combine the keys as you like, and put them where you want. I'd have to think a few minutes about the deep merge, and have some specifics.
Visiting each key-value pair in a map and transforming each value according to some rule is easy in C++. (for (auto & p : my_map) p.second = foo(p.second); or something like that) Adding the accumulation would be done in foo or whatever lambda is used, but it's not difficult.
Making a full functional language would be more difficult, but I just don't see how Haskell, or any other programming language, can be that much easier than C++ for a lot of the examples you've given.
It also seems to me it would be significantly more difficult to do in C, which is why I consider C++ much more expressive than C.
I get the impression that you aren't familiar enough with C++ to appreciate its flexibility and expressiveness, much as I'd have a lot of trouble expressing common C++ stuff in Haskell.
Or you're in one of those problem areas where the fastest known algorithms are slow even when properly coded. The software I'm working on is well maintained and we're always willing to entertain new algorithms. Our code quality is too high. Our code is too slow and everybody would like it to be faster.
C++ isn't C with Classes any more, and hasn't been for decades. C++ has all sorts of tools you can use as you see fit. If OO doesn't fit your problem, don't use it.
Why do you think it's hard to write really efficient C++? I haven't noticed it being any harder than in C, assuming equal functionality.
Nope. A few weeks proves nothing about climate. When the weather changes consistently, and things happen fairly frequently over a period of years that almost never happened before, that's climate.
It almost never rained in winter when I was a kid. Now that I'm older and in the same city, we've had fairly frequent rain in winter for quite a few years now. That's probably climate change, but of course says very little about global warming.
In this case, something happened that had been considered almost completely impossible. One characteristic of climate change is that extreme events move from the nearly impossible to the highly improbable, so one unbelievable event happening does provide evidence.
With the Swedish extradition request, the UK could not have legally extradited Assange to the US. He was safer from the US because of the extradition request.
Assange voluntarily traveled to Sweden, and then to the UK. Going to the UK is a very strange thing to do for someone who fears a US extradition request.
I don't understand the Swedish justice system in any detail, and I distrust accounts from people who aren't authorities and don't cite sources. Trials in absentia are abominations. I see no inconsistency in Sweden's waiting until they can get custody of a suspect to proceed with a case.
Every so often, rape victims call for charges to be dropped, for various reasons. That doesn't mean innocence.
I'm not taking any position on the accuracy of the statements, but one woman accused Assange of holding her down, forcibly removing her clothing, and refusing to wear a condom. Another accused Assange of sex without a condom while she was sleeping. Both of these would be considered felonies whee I live.
C++ is subject to a lot fewer errors than C, although there are some. C++ memory management is generally fairly painless (although you have to pay some attention to detail) until you get a circular shared_ptr list. Even that just leaks memory rather than corrupting anything.
In other words, you're working in a post-Brooks environment, incorporating a lot of ideas that were first widely disseminated in the software field by Brooks.
There's a lot of the book that's irrelevant, nowadays, either common knowledge or (in the light of later knowledge) wrong or dependent on technological limitations nobody has anymore. There's also things that people just don't seem to have learned.
My experience is that decomposition is not a silver bullet. Things never break down as cleanly as you'd like, and there will be things you misestimated or overlooked at the start, and surprises where the intended approach isn't going to work.
Brooks was overstating Brooks' Law, but he appears to have been going for impact rather than precision.
When I'm on a road trip, it's almost always with my wife or some friends. I don't live such a sad and pathetic life that I have to drive hundreds of miles by myself.
It's not so much that vehicles are standing still on the way north, although I've seen that happen, as that there's lots of them. If even a small percentage were low on charge, for whatever reason, the lines for chargers would be pretty long.
I may well have been overgeneralizing from one example, but we used to go on road trips almost immediately on getting home. Throw stuff into the back and go. Leave the interstate after about an hour and spend the next three and a half on increasingly insignificant roads.
Sure. Antibiotics are good, but not always essential. Lots of people survive infections without antibiotics. Lots more survive with.
Antibiotic-resistant bacteria are bad, but they aren't a certain death sentence.
The Keynesian method, which nobody seems to practice, is to have some austerity going in good times and forget about it in bad. Too many countries seem to forget about trying to save in good times (the Clinton administration is an exception). Austerity in bad times generally makes them worse. It's cost the Greek economy dearly.
For my last surgery, I was on antibiotics before and after.
There's two stages of drug research.
One is finding something that looks promising. Some of this is done by Big Pharma, but a lot is publicly subsidized. It's not necessarily that expensive, so we can profitably keep a lot of labs working on it.
The second is turning something that looks promising into an actual drug that can be used on humans. That's really expensive. It may be necessary to make a lot of molecular changes to the drug, and it may never turn into something significantly deadlier to bacteria than people. Each attempt requires a lot of scarce resources, and I'm happier with numerous people deciding which to pursue rather than having drug research collapse if one authority screws up bad. Having the market decide which avenues to pursue works as long as the profit motive aligns with what we need. If it doesn't, we can make it work. There's a lot of conditions that affect only enough people for FDA-required testing, so, once a drug were released for sale, nobody would buy it. We have some government programs to provide artificial profit for such orphan drugs.
It may surprise you, but the FDA only has authority in the US, and there are in fact civilized areas outside the US. Some of them have their own big pharma companies and everything!
While Western Europe and Japan do better with public health than we do, it's not miraculously better.
Death and rape threats from anonymous sources combined with information necessary to carry out the threat are at least somewhat credible.
Aside from the fact that you have no sense of humor, antibiotic-resistant infections are often curable. People got sick and got well before antibiotics, and they still get sick and well with viruses.
- Has one or more pieces of Windows-only software that they use and are unwilling or unable to change.
Apple discontinuing product support for a company they bought has lots of possible reasons, and has nothing to do with Apple's motivation for pairing the fingerprint scanner.
Once upon a time, nobody had any security on their iPhones. The PIN was seen as too much work. The fingerprint sensor (which can be disabled if you like) was put there to get people to have some security without inconveniencing them too much.
I took a look at the repair guide for my boiler in the basement. I can't understand it, and if I did I would still not have the tools and measurement devices.