I'm hoping for a hung Parliament or at least the Tories getting no better than a reduced majority and consequently needing to rely on more support from Parliament as a whole to get anything controversial done.
If that means Theresa May goes then that's a plus. I don't think she's a good PM, and it appears that many of the government policies that I disagree with originated in her office.
If it means that there is less headline-friendly political meddling in negotiating Brexit and the diplomats can quietly get on with it in the background and reach a reasonable agreement with their diplomatic counterparts, then as far as I'm concerned that is probably also a good thing. The last thing any of us need, on either side of the Channel, is a Brexit negotiation conducted through media soundbites by vulnerable Tory ministers from one side and wounded EU politicians like Jean-Claude Juncker from the other.
Well, there's always interpretation in these things, but this is a Tier 1 visa, essentially the top level. To put this story in perspective, it made the news because they issued more than their normal quota of 200 of these for applicants from across the entire world within an entire year.
There are some slightly vague criteria for tech visas, including some adjustments depending on things like whether someone is planning to bring key tech skills to the main northern cities. However, for comparison, this is probably the kind of visa you get if you're a post-doctoral researcher, internationally acclaimed architect, performer who plays sell-out gigs in major venues, serial entrepreneur with successful IPOs behind you, and so on.
In short, exceptional means you have to be good enough at something that it's worth letting you off the normal Tier 2 visa rules about requiring a job with an approved sponsor before coming to work here long term and bringing dependents.
There is a reason that level of visa has the word "exceptional" in its title, though. You don't get one of those if you worked at Google for a couple of years. You get one of those if you're Sergey Brin or Larry Page.
I always wondered about this. Unless something changed, I thought that GitHub's official policy was that one person is only allowed one (non-paid) account, possibly with some exceptions for things like well-known projects. But IME there are mostly only two kinds of developer: those who don't really use GitHub much other than anonymously pulling from the repos, and those who are really into it and often do seem to have several different accounts they use.
Not that I think you're wrong, but is this really so different to the Visual Basic or PHP "developers" of yesteryear? Maybe JS is just the latest language that everyone automatically has on their computers and where it's easy to find beginner tutorials (good, bad or otherwise) online.
If there were 5 million in 2012 and 20 million in 2017, that's probably only a million JS programmers, they just created new names for everything every few months...
It may be relatively easy to get access to some copy. However, it's also relatively easy to ensure that only the intended recipient first receives a specific watermarked copy. We're talking about systems that will probably have a substantial price tag and need some sort of installation here, not things you can just walk into your local store and buy anonymously.
I'm wary of writing anything about anyone's specific product, even pseudonymously, given the online video industry is pretty litigious and there are NDAs and patents all over the place. If you'd like to read up on some papers, Google Scholar does have loads of them (though unfortunately many aren't worth much, being light on detail and written in very broken English).
Essentially, though, many of the more attack-resistant watermarking strategies no longer rely purely on spatial data but instead make changes within frequency space that are then effectively distributed throughout the frame (or some block(s) within it). If you'd like to do some wider reading, you could search for techniques involving discrete cosine transforms or wavelets as a starting point. Alternatively, you could search for watermarking strategies designed to resist specific attacks (cropping, rotation, etc.) and you'll probably find a lot of the same material.
I'm not sure you're talking about the same kinds of watermarks as everyone else here.
Watermarking in the sense of digital content protection usually refers to embedded some sort of signature, possibly unique to each recipient, within the underlying data. We're not talking about some TV studio's overt branding in the corner of the video, or anything else so crude.
Also, we're not talking about preventing a copy from being released. We're talking about having robust evidence if you find a leaked copy of exactly where it came from, so you can (for example) cut off access to the person responsible or take legal action against them.
No modern watermarking system that I know of is this easy to defeat. You seem to be looking at the problem in terms of single, independent pixels. You have to look at it the same way you would if, for example, you were writing a compression algorithm.
Since by far most movies can't survive without box office sales, they win.
Not yet, perhaps. But going by the experiences of Netflix and friends, the world is moving rapidly towards on-demand streaming from the comfort of your own home as the technology improves. I personally don't go to the cinema much any more: it's much less convenient and even mid-range home equipment can produce video and audio quality close enough not to mind the difference these days. However, I probably would sign up for a Netflix-style "big movies from day one" service if the price was right (as long as it just showed me the video when I wanted to watch it -- none of this excessive surveillance crap).
If you can trivially get many streams with unique watermarks then it's extremely hard to hide the nature of the watermark and and prevent anyone from destroying it.
It really isn't. A good watermark will be more like a good hash: a slight change in the input results in a very different output. A diff of two (or more) watermarked videos would just show almost entirely different data in every case. And while you could run the actual image data through lossy transformations to try to even out any distortions small enough to be invisible to the naked eye, you'd probably have to degrade the quality so much to reliably remove all traces of the underlying watermarks that the footage would be practically unwatchable.
Presumably most people still assume that anything they can't see in a video is invisible to everyone else as well. Real video watermarking today is more like security pens: you can barely see what they write normally, but under a UV light it becomes clear as day, and getting rid of all traces is surprisingly difficult.
Since most people don't have the mathematical equivalent of a UV light, they'd unaware that the watermark is even there, but tracing a leak would be pretty easy if the originator found a copy on something like a P2P network unless the quality of the signal was compromised so much that the video itself had become almost useless anyway.
As someone involved with a similar service: Of course they do. And they know very well when you're doing it, too, because the differences in access patterns are obvious.
In the long run, turning a blind eye to people who are bending the rules a bit often works out better for everyone than cracking down on the slightest infringement. The business gets to keep customers who are paying their way (more or less) happy and loyal. The basically decent customers get to use the service in ways that are convenient at a price they can afford. And any resources available to deal with piracy can be directed to those who are flagrantly violating the agreement.
If you do have a go at writing the equivalent of those two functions in C++ later, in either functional or imperative style, please do post what you come up with. I'd be very interested to see the results, and in particular whether you know some tricks that I don't to keep the C++ code tidy or whether perhaps you're just more forgiving of less than ideal syntax while I've been spoiled by some of the other languages I use more than C++ these days and become a language snob.;-)
I agree that to those familiar with functional programming concepts, map and reduce are at least as legible as explicit loops. However, I do think that due to their nature as higher-level abstractions that fluency in these concepts requires a greater effort.
That seems logical. In other disciplines we have to learn some new concepts and terminology before we can communicate effectively with other practitioners or use more advanced tools built on those concepts.It seems reasonable to assume the same is true for programming in a more functional style.
Of course, it could be simply the case that most people are introduced to programming in imperative programming languages.
I suspect this is true as well. I haven't seen very much formal research on this, so most of what I have to go on is just personal experience and anecdote. That said, when I have taught someone to program from scratch, I have generally tried to avoid tunnel vision about any particular language or style, preferring to focus on the underlying concepts as much as possible. From that experience, it seems that which tools a student finds intuitive at first often has little to do with any particular programming style, or indeed with what experienced programmers from any given background might assume was difficult.
For example, I've seen someone who had been learning for a relatively short time find a ternary if expression completely natural to the point where they would happily replace imperative if-else constructions with it wherever they could. However, the same person at the same time preferred loops with an explicit variable and steps that they could see over using named algorithms like map or filter where some of the control flow was implicit. They also had more difficulty understanding loop structures where the control variable iterates through indices or keys and the corresponding values then have to be looked up indirectly, and found loops much easier to understand if the control variable iterates through the values directly.
One possibility there is that the ease or difficulty of understanding related to how much indirection or composition was involved. Loops over indices/keys and mapping with a transformation function both require a sort of mental jump to get down to the real data you're working with. A loop over values or a ternary if does not.
Another possibility is that the student was still thinking on the level of individual operations on each data point rather than operations on a collection as a whole. The ternary if or value-based loop let them focus on a single value at once, and they could put a logging statement straight after the conditional or in each iteration of the loop and follow the values being transformed as their program ran. (It's probably worth mentioning that at this stage, we hadn't yet looked at much in the way of non-trivial data structures and algorithms. I'm talking about a time full of first impressions here.)
It would be fascinating to see what real psychologists could come up with if they studied this sort of early learning behaviour in programming students starting from a true clean slate, but there probably aren't that many opportunities to make careful observations in that sort of environment. I've only been able to gather the experience I described above because I happen to have a few friends and family who have decided for one reason or another that they wanted to learn some real programming skills and they weren't doing so either through academic study or as part of a current job.
This sort of brings us to your final question, and for me the answer is a qualified yes. I do think programming education, particularly in a professional environment, would do well to teach a broader range of concepts than traditionally it has (outside of a few university CS/SE courses that do touch on other styles like functional and logic programming). But there is a chicken-and-egg problem here too, because although some of the c
I'm wary of speculating or trusting early information too much in a situation like this. The truth is that I have no idea how many people actually come to the attention of the police and security services so many times or for reasons as disturbing as saying they think suicide bombing is OK. It seems likely that in this case something has gone wrong with the system, obviously with horrible consequences, and no doubt there will be a lot of reviews and discussions in the weeks and months ahead to try and work out whether anything could be done better to reduce the danger in the future.
However, if the reports are broadly accurate and that much direct warning wasn't enough to allocate resources and intervene to prevent the attack at any stage, it seems even less likely that fishing expeditions based on extensive monitoring of online communications would have led to a better conclusion.
The tradeoff with the functional languages of course is that reasoning about the code becomes more difficult
Interesting comment. I would have argued in the opposite direction: assuming a similar level of familiarity with the languages and programming styles, it is often easier to reason about functional code than about imperative code where you might have expressed the equivalent behaviour through nested loops and so on.
That assumption about familiarity is important. If you're not reading functions like mapMaybe and unionWith in my example with the same fluency that you'd read
for (int i = 0; i < numThings; ++i) {... }
in an imperative equivalent then naturally understanding the functional code is going to be harder work, and likewise the other way around. However, other things being equal, my experience has been that decent code written with these tools can often wind up more succinct, more explicit about following common programming patterns, and/or more amenable to rigorous analysis if the tools offer stronger guarantees about their behaviour than lower-level equivalents like writing loops or concurrency and synchronisation logic manually.
Of course, you can also write horrors in a language like Haskell that would make IOCCC veterans run crying for their mummy. There is definitely a danger of trying to be too clever with all the functional tools, when just writing something simple and explicit would have been a much better idea.
and mathematical elegance doesn't always translate into reasonable runtime requirements.
That is definitely a valid concern, and certainly these functional tools and the programming style they support aren't a good fit for every job. However, you could make the same argument about the language and library features that are already available in standard C++ and heading in this sort of direction. The original claim that I disputed was that C++ supports everything that other modern languages provide, in response to my own position that expressivity isn't a relative strength of C++ any more. Clearly in this area, among others I mentioned, it does not.
...Mainstream media are reporting today that the government was given credible warnings about the suspected bomber as many as five times over the past few years, from a variety of sources and via exactly the sorts of channels you're supposed to use if you're worried that someone might do something like this. None of these source appear to have relied on high-tech surveillance and intercepted communications. They were reportedly based on in-person observations, which tragically doesn't seem to have set off the right alarm bells soon enough.
OK, here's a concrete example I wrote for serviscope_minor the other day. I couldn't figure out how to post it at the time, but apparently if I set my posting mode to Code then it might work...
I'm assuming we're all geeks here, so let's suppose we're flying our starship to a space station and interested in the upgrades available from the merchants in the market there. The available upgrades are either weapons with a certain level of firepower or fuel tanks with a certain capacity, and each of them mounts at a specific point on our ship. Each merchant has a price list of the upgrades they have available and what they cost.
The next part of this post contains a complete, working Haskell program that sets up a few simple data types and helper functions to model this domain, and then creates a not entirely trivial data structure to represent what's available in that station market. The interesting part is near the end, when we want to start working with that data, and it's the functions that are just a line or two long. If you'd like to build this code for yourself, it should compile fine with any recent GHC and no special options required, and it just needs the base, containers and pretty-show libraries. So, here's the program:
module Main where
import qualified Data.Map.Strict as M import Data.Maybe (mapMaybe) import Text.Show.Pretty (ppShow)
type Capacity = Int type Firepower = Int data Upgrade = FuelTank Capacity | Weapon Firepower deriving (Show, Eq)
For one thing, C is exceptionally well defined and has a very clean syntax
Well defined, I'll agree with. The ISO standards for both C and C++ are much more rigorous than the foundations for a lot of programming languages.
Whether it's a good definition is a different question. For example, C also has the dubious honour of being one of the only mainstream programming languages where its specification deliberately and explicitly makes the results of some actions undefined behaviour. There is really no need for a language, even one designed to support low-level systems programming, to default to a nullable pointer type with full arithmetic support and provide no safer alternative. There is no need to have fundamentally unsafe library functions like gets lying around either. Implicit and potentially lossy type conversions. Unions. Enumerations. Macros. The list of hazardous areas is quite extensive for a relatively small language, the list of bugs that has originated in those areas is quite extensive as well.
As for the syntax, again I think it's hit and miss. The basic structured programming stuff is fine, but the "inside out" notation for types is a classic example of something we're now stuck with primarily because of momentum and familiarity, even though it's a terrible design by just about any other reasonable standard.
Much of this could be improved on technical grounds without resorting to dramatic changes. I'm totally with you on not seeing things like Java as moves in the right direction, for the kind of programming jobs that I think we're talking about where C was a sensible choice in the first place. But alas, the programming industry rarely moves from one major language to another just because the second one includes lots of useful but modest and incremental improvements rather than any new killer feature. Even the Python community has taken quite a few years to shift its focus from mostly 2 to mostly 3, and that's without the practical constraints on compatibility and portability that C needs to do its job.
There's a long scale between "knows nothing" and "full mastery", though. If we're talking about someone making non-trivial changes to existing code or doing new development work, then in my experience competence arrives somewhere in the middle of the scale, and is almost invariably accompanied by significant experience with the actual language/libraries/tools being used and in the same field as the application being developed.
However, between "knows nothing" and that "competence" region on the scale, there is also the "knows just enough to be dangerous" region. This is where someone with a general programming background but experience only with other tools or areas of application tends to land, and how far up tends to depend on how close what they've used or done before is to what they'll be using or doing now.
Now, it's certainly possible that someone who has broad general programming skills, joining a project using a new language but one that is very similar in style to things they've done before, will arrive already close to the top end of the "just enough to be dangerous" region, and will then learn quickly and soon be able to move to the lower end of "competence".
But I still think it's a nonsense to suggest that any "competent" programmer would necessarily land so far up the scale working on any new project written in any new language without considering how similar it was to anything they'd done before. Someone could be a fine programmer with significant skill and experience in writing the back-end of web sites using Ruby or Python, yet not have the slightest clue how to organise a large-scale distributed telecom system written in Erlang. Someone could be a wizard at developing that Erlang telecom system, yet not have a clue how to write tight C code that can run on an embedded device with very little memory.
Slashdot Mirror
I'm hoping for a hung Parliament or at least the Tories getting no better than a reduced majority and consequently needing to rely on more support from Parliament as a whole to get anything controversial done.
If that means Theresa May goes then that's a plus. I don't think she's a good PM, and it appears that many of the government policies that I disagree with originated in her office.
If it means that there is less headline-friendly political meddling in negotiating Brexit and the diplomats can quietly get on with it in the background and reach a reasonable agreement with their diplomatic counterparts, then as far as I'm concerned that is probably also a good thing. The last thing any of us need, on either side of the Channel, is a Brexit negotiation conducted through media soundbites by vulnerable Tory ministers from one side and wounded EU politicians like Jean-Claude Juncker from the other.
Well, there's always interpretation in these things, but this is a Tier 1 visa, essentially the top level. To put this story in perspective, it made the news because they issued more than their normal quota of 200 of these for applicants from across the entire world within an entire year.
There are some slightly vague criteria for tech visas, including some adjustments depending on things like whether someone is planning to bring key tech skills to the main northern cities. However, for comparison, this is probably the kind of visa you get if you're a post-doctoral researcher, internationally acclaimed architect, performer who plays sell-out gigs in major venues, serial entrepreneur with successful IPOs behind you, and so on.
In short, exceptional means you have to be good enough at something that it's worth letting you off the normal Tier 2 visa rules about requiring a job with an approved sponsor before coming to work here long term and bringing dependents.
The survival of the NHS, for one thing?
There is a reason that level of visa has the word "exceptional" in its title, though. You don't get one of those if you worked at Google for a couple of years. You get one of those if you're Sergey Brin or Larry Page.
I always wondered about this. Unless something changed, I thought that GitHub's official policy was that one person is only allowed one (non-paid) account, possibly with some exceptions for things like well-known projects. But IME there are mostly only two kinds of developer: those who don't really use GitHub much other than anonymously pulling from the repos, and those who are really into it and often do seem to have several different accounts they use.
Not that I think you're wrong, but is this really so different to the Visual Basic or PHP "developers" of yesteryear? Maybe JS is just the latest language that everyone automatically has on their computers and where it's easy to find beginner tutorials (good, bad or otherwise) online.
If there were 5 million in 2012 and 20 million in 2017, that's probably only a million JS programmers, they just created new names for everything every few months...
It may be relatively easy to get access to some copy. However, it's also relatively easy to ensure that only the intended recipient first receives a specific watermarked copy. We're talking about systems that will probably have a substantial price tag and need some sort of installation here, not things you can just walk into your local store and buy anonymously.
I'm wary of writing anything about anyone's specific product, even pseudonymously, given the online video industry is pretty litigious and there are NDAs and patents all over the place. If you'd like to read up on some papers, Google Scholar does have loads of them (though unfortunately many aren't worth much, being light on detail and written in very broken English).
Essentially, though, many of the more attack-resistant watermarking strategies no longer rely purely on spatial data but instead make changes within frequency space that are then effectively distributed throughout the frame (or some block(s) within it). If you'd like to do some wider reading, you could search for techniques involving discrete cosine transforms or wavelets as a starting point. Alternatively, you could search for watermarking strategies designed to resist specific attacks (cropping, rotation, etc.) and you'll probably find a lot of the same material.
I'm not sure you're talking about the same kinds of watermarks as everyone else here.
Watermarking in the sense of digital content protection usually refers to embedded some sort of signature, possibly unique to each recipient, within the underlying data. We're not talking about some TV studio's overt branding in the corner of the video, or anything else so crude.
Also, we're not talking about preventing a copy from being released. We're talking about having robust evidence if you find a leaked copy of exactly where it came from, so you can (for example) cut off access to the person responsible or take legal action against them.
No modern watermarking system that I know of is this easy to defeat. You seem to be looking at the problem in terms of single, independent pixels. You have to look at it the same way you would if, for example, you were writing a compression algorithm.
Since by far most movies can't survive without box office sales, they win.
Not yet, perhaps. But going by the experiences of Netflix and friends, the world is moving rapidly towards on-demand streaming from the comfort of your own home as the technology improves. I personally don't go to the cinema much any more: it's much less convenient and even mid-range home equipment can produce video and audio quality close enough not to mind the difference these days. However, I probably would sign up for a Netflix-style "big movies from day one" service if the price was right (as long as it just showed me the video when I wanted to watch it -- none of this excessive surveillance crap).
If you can trivially get many streams with unique watermarks then it's extremely hard to hide the nature of the watermark and and prevent anyone from destroying it.
It really isn't. A good watermark will be more like a good hash: a slight change in the input results in a very different output. A diff of two (or more) watermarked videos would just show almost entirely different data in every case. And while you could run the actual image data through lossy transformations to try to even out any distortions small enough to be invisible to the naked eye, you'd probably have to degrade the quality so much to reliably remove all traces of the underlying watermarks that the footage would be practically unwatchable.
Presumably most people still assume that anything they can't see in a video is invisible to everyone else as well. Real video watermarking today is more like security pens: you can barely see what they write normally, but under a UV light it becomes clear as day, and getting rid of all traces is surprisingly difficult.
Since most people don't have the mathematical equivalent of a UV light, they'd unaware that the watermark is even there, but tracing a leak would be pretty easy if the originator found a copy on something like a P2P network unless the quality of the signal was compromised so much that the video itself had become almost useless anyway.
As someone involved with a similar service: Of course they do. And they know very well when you're doing it, too, because the differences in access patterns are obvious.
In the long run, turning a blind eye to people who are bending the rules a bit often works out better for everyone than cracking down on the slightest infringement. The business gets to keep customers who are paying their way (more or less) happy and loyal. The basically decent customers get to use the service in ways that are convenient at a price they can afford. And any resources available to deal with piracy can be directed to those who are flagrantly violating the agreement.
If you do have a go at writing the equivalent of those two functions in C++ later, in either functional or imperative style, please do post what you come up with. I'd be very interested to see the results, and in particular whether you know some tricks that I don't to keep the C++ code tidy or whether perhaps you're just more forgiving of less than ideal syntax while I've been spoiled by some of the other languages I use more than C++ these days and become a language snob. ;-)
I agree that to those familiar with functional programming concepts, map and reduce are at least as legible as explicit loops. However, I do think that due to their nature as higher-level abstractions that fluency in these concepts requires a greater effort.
That seems logical. In other disciplines we have to learn some new concepts and terminology before we can communicate effectively with other practitioners or use more advanced tools built on those concepts.It seems reasonable to assume the same is true for programming in a more functional style.
Of course, it could be simply the case that most people are introduced to programming in imperative programming languages.
I suspect this is true as well. I haven't seen very much formal research on this, so most of what I have to go on is just personal experience and anecdote. That said, when I have taught someone to program from scratch, I have generally tried to avoid tunnel vision about any particular language or style, preferring to focus on the underlying concepts as much as possible. From that experience, it seems that which tools a student finds intuitive at first often has little to do with any particular programming style, or indeed with what experienced programmers from any given background might assume was difficult.
For example, I've seen someone who had been learning for a relatively short time find a ternary if expression completely natural to the point where they would happily replace imperative if-else constructions with it wherever they could. However, the same person at the same time preferred loops with an explicit variable and steps that they could see over using named algorithms like map or filter where some of the control flow was implicit. They also had more difficulty understanding loop structures where the control variable iterates through indices or keys and the corresponding values then have to be looked up indirectly, and found loops much easier to understand if the control variable iterates through the values directly.
One possibility there is that the ease or difficulty of understanding related to how much indirection or composition was involved. Loops over indices/keys and mapping with a transformation function both require a sort of mental jump to get down to the real data you're working with. A loop over values or a ternary if does not.
Another possibility is that the student was still thinking on the level of individual operations on each data point rather than operations on a collection as a whole. The ternary if or value-based loop let them focus on a single value at once, and they could put a logging statement straight after the conditional or in each iteration of the loop and follow the values being transformed as their program ran. (It's probably worth mentioning that at this stage, we hadn't yet looked at much in the way of non-trivial data structures and algorithms. I'm talking about a time full of first impressions here.)
It would be fascinating to see what real psychologists could come up with if they studied this sort of early learning behaviour in programming students starting from a true clean slate, but there probably aren't that many opportunities to make careful observations in that sort of environment. I've only been able to gather the experience I described above because I happen to have a few friends and family who have decided for one reason or another that they wanted to learn some real programming skills and they weren't doing so either through academic study or as part of a current job.
This sort of brings us to your final question, and for me the answer is a qualified yes. I do think programming education, particularly in a professional environment, would do well to teach a broader range of concepts than traditionally it has (outside of a few university CS/SE courses that do touch on other styles like functional and logic programming). But there is a chicken-and-egg problem here too, because although some of the c
According to the front page story in today's Telegraph, a mosque banned him and reported him to the authorities because of his extremist views.
I'm wary of speculating or trusting early information too much in a situation like this. The truth is that I have no idea how many people actually come to the attention of the police and security services so many times or for reasons as disturbing as saying they think suicide bombing is OK. It seems likely that in this case something has gone wrong with the system, obviously with horrible consequences, and no doubt there will be a lot of reviews and discussions in the weeks and months ahead to try and work out whether anything could be done better to reduce the danger in the future.
However, if the reports are broadly accurate and that much direct warning wasn't enough to allocate resources and intervene to prevent the attack at any stage, it seems even less likely that fishing expeditions based on extensive monitoring of online communications would have led to a better conclusion.
The tradeoff with the functional languages of course is that reasoning about the code becomes more difficult
Interesting comment. I would have argued in the opposite direction: assuming a similar level of familiarity with the languages and programming styles, it is often easier to reason about functional code than about imperative code where you might have expressed the equivalent behaviour through nested loops and so on.
That assumption about familiarity is important. If you're not reading functions like mapMaybe and unionWith in my example with the same fluency that you'd read
for (int i = 0; i < numThings; ++i) { ... }
in an imperative equivalent then naturally understanding the functional code is going to be harder work, and likewise the other way around. However, other things being equal, my experience has been that decent code written with these tools can often wind up more succinct, more explicit about following common programming patterns, and/or more amenable to rigorous analysis if the tools offer stronger guarantees about their behaviour than lower-level equivalents like writing loops or concurrency and synchronisation logic manually.
Of course, you can also write horrors in a language like Haskell that would make IOCCC veterans run crying for their mummy. There is definitely a danger of trying to be too clever with all the functional tools, when just writing something simple and explicit would have been a much better idea.
and mathematical elegance doesn't always translate into reasonable runtime requirements.
That is definitely a valid concern, and certainly these functional tools and the programming style they support aren't a good fit for every job. However, you could make the same argument about the language and library features that are already available in standard C++ and heading in this sort of direction. The original claim that I disputed was that C++ supports everything that other modern languages provide, in response to my own position that expressivity isn't a relative strength of C++ any more. Clearly in this area, among others I mentioned, it does not.
...Mainstream media are reporting today that the government was given credible warnings about the suspected bomber as many as five times over the past few years, from a variety of sources and via exactly the sorts of channels you're supposed to use if you're worried that someone might do something like this. None of these source appear to have relied on high-tech surveillance and intercepted communications. They were reportedly based on in-person observations, which tragically doesn't seem to have set off the right alarm bells soon enough.
In case you're still interested, I did find a way to post that longer example eventually. You can find it here.
OK, here's a concrete example I wrote for serviscope_minor the other day. I couldn't figure out how to post it at the time, but apparently if I set my posting mode to Code then it might work...
:: Upgrade -> Bool
:: Upgrade :: MountPoint :: Cost
:: Market
:: Market -> [Merchant]
:: SaleItem -> Maybe (MountPoint, Firepower)
:: Market -> M.Map MountPoint Firepower
I'm assuming we're all geeks here, so let's suppose we're flying our starship to a space station and interested in the upgrades available from the merchants in the market there. The available upgrades are either weapons with a certain level of firepower or fuel tanks with a certain capacity, and each of them mounts at a specific point on our ship. Each merchant has a price list of the upgrades they have available and what they cost.
The next part of this post contains a complete, working Haskell program that sets up a few simple data types and helper functions to model this domain, and then creates a not entirely trivial data structure to represent what's available in that station market. The interesting part is near the end, when we want to start working with that data, and it's the functions that are just a line or two long. If you'd like to build this code for yourself, it should compile fine with any recent GHC and no special options required, and it just needs the base, containers and pretty-show libraries. So, here's the program:
module Main where
import qualified Data.Map.Strict as M
import Data.Maybe (mapMaybe)
import Text.Show.Pretty (ppShow)
type Capacity = Int
type Firepower = Int
data Upgrade = FuelTank Capacity | Weapon Firepower deriving (Show, Eq)
isFuelTankUpgrade
isFuelTankUpgrade (FuelTank _) = True
isFuelTankUpgrade _ = False
data MountPoint = LeftWing | RightWing | Tail | Dorsal | Ventral
deriving (Show, Eq, Ord)
type Cost = Int
data SaleItem = SaleItem { upgrade
, mountPoint
, cost
} deriving (Show, Eq)
type Merchant = String
type Market = M.Map Merchant [SaleItem]
spaceStationMarket
spaceStationMarket = M.fromList
[ ( "Bob's Bombs"
, [ SaleItem (Weapon 200) LeftWing 250
, SaleItem (Weapon 200) RightWing 250
, SaleItem (Weapon 100) LeftWing 100
, SaleItem (Weapon 100) RightWing 100
, SaleItem (Weapon 400) Ventral 750
]
)
, ( "Rory's Range Enhancers"
, [ SaleItem (FuelTank 1000) LeftWing 50
, SaleItem (FuelTank 1000) RightWing 50
]
)
, ( "Dora's Defences"
, [ SaleItem (Weapon 50) Dorsal 50
, SaleItem (Weapon 50) Ventral 50
, SaleItem (Weapon 50) Tail 50
, SaleItem (FuelTank 2000) Ventral 150
]
)
]
fuelTankStores
fuelTankStores = M.keys . (M.filter (any (isFuelTankUpgrade . upgrade)))
mountedFP
mountedFP (SaleItem (Weapon fp) mp _) = Just (mp, fp)
mountedFP _ = Nothing
maxFPAvailablePerMP
maxFPAvailablePerMP priceLists =
let maxFPsPerMerchant = M.map ((M.fromListWith max) . (mapMaybe mountedFP)) price
For one thing, C is exceptionally well defined and has a very clean syntax
Well defined, I'll agree with. The ISO standards for both C and C++ are much more rigorous than the foundations for a lot of programming languages.
Whether it's a good definition is a different question. For example, C also has the dubious honour of being one of the only mainstream programming languages where its specification deliberately and explicitly makes the results of some actions undefined behaviour. There is really no need for a language, even one designed to support low-level systems programming, to default to a nullable pointer type with full arithmetic support and provide no safer alternative. There is no need to have fundamentally unsafe library functions like gets lying around either. Implicit and potentially lossy type conversions. Unions. Enumerations. Macros. The list of hazardous areas is quite extensive for a relatively small language, the list of bugs that has originated in those areas is quite extensive as well.
As for the syntax, again I think it's hit and miss. The basic structured programming stuff is fine, but the "inside out" notation for types is a classic example of something we're now stuck with primarily because of momentum and familiarity, even though it's a terrible design by just about any other reasonable standard.
Much of this could be improved on technical grounds without resorting to dramatic changes. I'm totally with you on not seeing things like Java as moves in the right direction, for the kind of programming jobs that I think we're talking about where C was a sensible choice in the first place. But alas, the programming industry rarely moves from one major language to another just because the second one includes lots of useful but modest and incremental improvements rather than any new killer feature. Even the Python community has taken quite a few years to shift its focus from mostly 2 to mostly 3, and that's without the practical constraints on compatibility and portability that C needs to do its job.
There's a long scale between "knows nothing" and "full mastery", though. If we're talking about someone making non-trivial changes to existing code or doing new development work, then in my experience competence arrives somewhere in the middle of the scale, and is almost invariably accompanied by significant experience with the actual language/libraries/tools being used and in the same field as the application being developed.
However, between "knows nothing" and that "competence" region on the scale, there is also the "knows just enough to be dangerous" region. This is where someone with a general programming background but experience only with other tools or areas of application tends to land, and how far up tends to depend on how close what they've used or done before is to what they'll be using or doing now.
Now, it's certainly possible that someone who has broad general programming skills, joining a project using a new language but one that is very similar in style to things they've done before, will arrive already close to the top end of the "just enough to be dangerous" region, and will then learn quickly and soon be able to move to the lower end of "competence".
But I still think it's a nonsense to suggest that any "competent" programmer would necessarily land so far up the scale working on any new project written in any new language without considering how similar it was to anything they'd done before. Someone could be a fine programmer with significant skill and experience in writing the back-end of web sites using Ruby or Python, yet not have the slightest clue how to organise a large-scale distributed telecom system written in Erlang. Someone could be a wizard at developing that Erlang telecom system, yet not have a clue how to write tight C code that can run on an embedded device with very little memory.