No, we don't overhire that much. I believe our attrition rate is normal for the industry.
We do have an internship program which feeds into hiring for permanent positions.
My point was that there are some successful IT companies that value older workers. Since there's a danger of losing expertise (to retirement, etc) when you have a lot of highly-experienced older workers, we also have to bring in younger ones and get them up to speed quickly. That's the only reason I mentioned hiring younger workers.
As near as I can tell, ALL companies hate old employees.
Not all. My employer (no points for figuring out who that is, since this is hardly privileged information) has for decades maintained a development workforce that's a healthy mix of older and younger employees. The field people - high-level support, SEs, consultants, etc - also skew older. Many of us have been here for a long time. Our experience is used, acknowledged, and compensated accordingly.
While we do bring in new people frequently, and mostly younger ones, they either quickly come up to speed, or they shake out into other parts of the organization or jobs elsewhere.
Of course it's not a perfect employment situation; what is? There have been episodes of layoffs. There's always the danger that older workers who have critical knowledge will leave one way or another; we try to make sure knowledge gets spread around and younger folks get training, mentoring, and exposure to tacit knowledge about products. And I'm sure that there have been cases where an argument for ageist discrimination could be made. But it's clearly not systemic the way it seems to be in many organizations, particularly in IT.
Now, I have to admit that we're profitable, which isn't the hip trend in IT these days. But, hey, someone's got to make money.
Poor workers are those who don't blame the tools, when the tools are at fault.
This maxim (apparently originally a Vietnamese saying, according to Wikiquote) is one of the dumber pieces of commonplace folk wisdom floating around the IT industry. It's precisely the sort of thing that makes it difficult to diagnose and resolve real problems.
Those fond of this saying need to learn a bit about the theory of failure. I don't care how you go about it - maybe try Schulz's Being Wrong - but learn a bit about failure modes and factors that contribute to them.
... are bound to become marketing executives, apparently. At any rate, anyone who thinks Mozilla has "paleotechnic origins" can safely be ignored. Even NCSA Mosaic, which is the earliest artifact you can reasonably claim as an "origin" of Mozilla, was only developed in freaking 1992. The TCP-goddamned-Internet had been around for nine years at that point. Mosaic was a contemporary of AOL for Windows and Eternal September.
Kids, lawn, &c.
And Mozilla itself, of course, is a mere teenager, as it was formed in 1998. If it's "paleo" anything, what does that make Oracle, Apple, Microsoft, Micro Focus - the surviving IT companies of the 1970s - Piacenzian? And IBM presumably is Burdigalian or something.
It was pretty amazing how useful and fast, even at 1200 baud, the Internet was back in the pre-graphics days. Gopher, Fetch, FTP, Whois an Usenet, and Lynx as a browser that focused on information, not self loading videos, animated ads, and other bandwidth and resource hogs.
I suppose it depends on what you mean by "the Internet". 1200 bps was fine for dialing into an Internet-connected server, for interactive use (I wrote a fair bit of code in editors like vi, EDIT/TPU, and XEDIT at 1200 bps) or for downloading files that weren't too large.
But if you actually wanted your machine to be on the Internet - to have an IP address and a route to the 'net - over, say, SLIP or PPP, you really wanted at least V.42, or something like one of the Telebit Trailblazer proprietary modes. Though UUCP was where the Telebits really shone, since they could do protocol spoofing and forward error correction.
And even then, I remember distinctly upgrading my remote office from a Trailblazer link to a dedicated 56Kbit line, and it was so much nicer not having to wait for the link to come back up every time it idled out. And then a few years later moved up again to ISDN BRI, with a shockingly fast bonded pair of 64K bps links. Sometimes even ran X11 over that one. Of course it was a three-mile walk through the snow to the office every day, but we were happy.
Besides z/OS, IBM still supports z/VSE on the z systems. It's the latest generation of DOS/VSE from the mid-1960s. We see a fair number of organizations still using it. And there's still zVM, which underpins z/OS and zLinux virtualization (the z hypervisor is basically a stripped-down zVM) but can also be used directly as an OS with CMS as the shell.
And there's IBM's i OS, which is the latest version of the S/38 and OS/400 line. Still widely used.
Bull still sells and develops GCOS (two different branches, apparently).
OS/2 is still around as eCommStation, and there's the announced (I think not yet released) ArcaOS derivative.
Kids these days. Remember when we used to complain about the "all the world's a VAX" generation?
No one claims that all "programming languages" need to be "turing complete."
Indeed, no one claimed that. Certainly I didn't.
The distinction between scripting language and "real programming language" imho is: Scripting language is executed from text (yes, might be jitted), has higher level constructs (e.g. pipes and processes in bash) probably has a REPL command line, "real programming languages" are usually compiled, have their abstractions on a different level (words, registers, classes, functions, lists, objects).
I'd call that a rather arbitrary list, and not to my mind particularly useful, but if it helps you sleep at night...
Of course both overlap.
Because it would be difficult to have only one overlap.
But calling a Scripting Language a "not a programming language" makes no sense.
Clearly it makes sense, or we wouldn't have any grounds for a comprehensible discussion of whether it's a true or useful statement. (An example of a statement that makes no sense is "a scripting language is not purple".) I don't think this mooted "scripting" versus "programming" distinction is sustainable or productive, though, so I'm a bit puzzled why you found it necessary to tell me it isn't.
Even in your CL example: you are running a program...does not matter if certain kinds of programs are impossible by design as it is not Turing complete.
Well, certainly it matters in some domains, since it determines whether certain computable functions can be implemented in that language. And "running a program" isn't a useful criterion, since it implies a circular definition (a programming language is one that can be used to create a program). But I agree it doesn't matter to the question of whether CL is a programming language.
Indeed, this was rather my point. There's a popular sentiment that HTML, say, is not a programming language, because it's not Turing-complete; I pointed out that there are languages which are intended for writing programs, and which practitioners recognize as programming languages, but which are also not TC. It's not the TC-nature of a language that makes it a programming language. In fact, as is generally the case with natural-language terms that are not well-defined as terms of art, whether something can be called a "programming language" ultimately comes down to whether your audience agrees with that use of the term.
All scripting languages are programming languages.
True by definition, I'd say, but there are scripting languages which are not Turing-complete and thus formally less powerful than what people usually consider "programming languages".
For example, CL (Control Language) on older versions of OS/400 had only one iteration construct: iterating over records in a file. And since file sizes were limited, every CL program is guaranteed to halt.[1]
That makes CL not-what-some-would-call-a-programming-language in a different sense than, say, a data-annotation language like HTML4 is.[2] Ultimately, I think, most people say HTML isn't a programming language because it's descriptive, while even CL is inherently imperative; it's a question of the modality you infer from the language.
But terms like "markup language", "scripting language", and "programming language", however common in the industry, aren't terms of art in software development or in computer science.[3] Traditionally (going back to the early decades of multiuser systems), "scripting language" was used for languages intended primarily for coordinating external components. The distinction has long-since blurred, and the terms are now used in broadly overlapping ways.
[1] And thus cannot be Turing-complete.
[2] HTML4 because HTML5 is forever a moving target, and who's to say WHAT-WG won't add full UTM capabilities to it tomorrow. And, yes, I know HTML5+CSS3 blah blah blah.
[3] In some cases they may be used as terms of art, of course, but then the authors are obliged to appeal to a particular definition. There's no broadly-accepted standard.
"Now"? They were suing left and right over things like their thumb wheel back when they were still Lawsuits In Motion. They've been litigation-happy since at least 2003, when they sued Xerox "defensively". They've been on the receiving end of many a patent dispute, too - and more than once lost a case. For a while there was an injunction forbidding them from selling Blackberry models in the US.
Same here - for my most recent mortgage. The underwriters wanted verification of the source of the down payment, even though it was an account in my name.
That wasn't the case for my previous mortgages, but underwriting has gotten much more strict in the US since 2008.
Obviously mirrors have failure modes as well. And generally speaking, more complexity means more failure modes, and often revenge effects as well.
(An example of a possible revenge effect with "virtual mirrors": Real side mirrors require the driver glance out the windows, which may lead to noticing something to the side that's not in the mirror's field of view. Screens won't require that, so drivers using them may miss hazards they otherwise would have noticed.)
The only sensible way to evaluate this change is with a well-conceived, fairly thorough threat model that looks at the likely failure modes, their consequences, and their probability. My guess is that if done well, "virtual mirrors" don't add that much risk, and largely compensate by reducing risk in other cases (e.g. low-light enhancement) - as long as the vehicle is decently maintained. But they'll be more prone to deterioration in old and unmaintained vehicles than mirrors are. Again, though, that's just a guess; it's all handwaving without a real threat model.
To say nothing of the Top Gear dog! (And we may ask, was Top Gear Germany based on JKJ's "Three Men on the Bummel"?)
I agree, though, that the three-hosts arrangement was indispensable to the TG formula, along with the "Ambitious but Rubbish" DIY disasters and general amateurishness, both of which are certainly features of "Three Men on a Boat".
Slashdot Mirror
How sad when names from an innocent game about child slavemasters running gladiatorial contests are used for something wicked.
Next they'll be using it to encourage loitering, trespassing, and distracted driving. Just you watch.
No, we don't overhire that much. I believe our attrition rate is normal for the industry.
We do have an internship program which feeds into hiring for permanent positions.
My point was that there are some successful IT companies that value older workers. Since there's a danger of losing expertise (to retirement, etc) when you have a lot of highly-experienced older workers, we also have to bring in younger ones and get them up to speed quickly. That's the only reason I mentioned hiring younger workers.
As near as I can tell, ALL companies hate old employees.
Not all. My employer (no points for figuring out who that is, since this is hardly privileged information) has for decades maintained a development workforce that's a healthy mix of older and younger employees. The field people - high-level support, SEs, consultants, etc - also skew older. Many of us have been here for a long time. Our experience is used, acknowledged, and compensated accordingly.
While we do bring in new people frequently, and mostly younger ones, they either quickly come up to speed, or they shake out into other parts of the organization or jobs elsewhere.
Of course it's not a perfect employment situation; what is? There have been episodes of layoffs. There's always the danger that older workers who have critical knowledge will leave one way or another; we try to make sure knowledge gets spread around and younger folks get training, mentoring, and exposure to tacit knowledge about products. And I'm sure that there have been cases where an argument for ageist discrimination could be made. But it's clearly not systemic the way it seems to be in many organizations, particularly in IT.
Now, I have to admit that we're profitable, which isn't the hip trend in IT these days. But, hey, someone's got to make money.
Poor workers are those who don't blame the tools, when the tools are at fault.
This maxim (apparently originally a Vietnamese saying, according to Wikiquote) is one of the dumber pieces of commonplace folk wisdom floating around the IT industry. It's precisely the sort of thing that makes it difficult to diagnose and resolve real problems.
Those fond of this saying need to learn a bit about the theory of failure. I don't care how you go about it - maybe try Schulz's Being Wrong - but learn a bit about failure modes and factors that contribute to them.
... are bound to become marketing executives, apparently. At any rate, anyone who thinks Mozilla has "paleotechnic origins" can safely be ignored. Even NCSA Mosaic, which is the earliest artifact you can reasonably claim as an "origin" of Mozilla, was only developed in freaking 1992. The TCP-goddamned-Internet had been around for nine years at that point. Mosaic was a contemporary of AOL for Windows and Eternal September.
Kids, lawn, &c.
And Mozilla itself, of course, is a mere teenager, as it was formed in 1998. If it's "paleo" anything, what does that make Oracle, Apple, Microsoft, Micro Focus - the surviving IT companies of the 1970s - Piacenzian? And IBM presumably is Burdigalian or something.
Unhappy with slow DSL? Switch to Comcast and be unhappy faster!
Really, the ad copy writes itself.
It was pretty amazing how useful and fast, even at 1200 baud, the Internet was back in the pre-graphics days. Gopher, Fetch, FTP, Whois an Usenet, and Lynx as a browser that focused on information, not self loading videos, animated ads, and other bandwidth and resource hogs.
I suppose it depends on what you mean by "the Internet". 1200 bps was fine for dialing into an Internet-connected server, for interactive use (I wrote a fair bit of code in editors like vi, EDIT/TPU, and XEDIT at 1200 bps) or for downloading files that weren't too large.
But if you actually wanted your machine to be on the Internet - to have an IP address and a route to the 'net - over, say, SLIP or PPP, you really wanted at least V.42, or something like one of the Telebit Trailblazer proprietary modes. Though UUCP was where the Telebits really shone, since they could do protocol spoofing and forward error correction.
And even then, I remember distinctly upgrading my remote office from a Trailblazer link to a dedicated 56Kbit line, and it was so much nicer not having to wait for the link to come back up every time it idled out. And then a few years later moved up again to ISDN BRI, with a shockingly fast bonded pair of 64K bps links. Sometimes even ran X11 over that one. Of course it was a three-mile walk through the snow to the office every day, but we were happy.
Besides z/OS, IBM still supports z/VSE on the z systems. It's the latest generation of DOS/VSE from the mid-1960s. We see a fair number of organizations still using it. And there's still zVM, which underpins z/OS and zLinux virtualization (the z hypervisor is basically a stripped-down zVM) but can also be used directly as an OS with CMS as the shell.
And there's IBM's i OS, which is the latest version of the S/38 and OS/400 line. Still widely used.
Bull still sells and develops GCOS (two different branches, apparently).
OS/2 is still around as eCommStation, and there's the announced (I think not yet released) ArcaOS derivative.
Kids these days. Remember when we used to complain about the "all the world's a VAX" generation?
No one claims that all "programming languages" need to be "turing complete."
Indeed, no one claimed that. Certainly I didn't.
The distinction between scripting language and "real programming language" imho is:
Scripting language is executed from text (yes, might be jitted), has higher level constructs (e.g. pipes and processes in bash) probably has a REPL command line, "real programming languages" are usually compiled, have their abstractions on a different level (words, registers, classes, functions, lists, objects).
I'd call that a rather arbitrary list, and not to my mind particularly useful, but if it helps you sleep at night...
Of course both overlap.
Because it would be difficult to have only one overlap.
But calling a Scripting Language a "not a programming language" makes no sense.
Clearly it makes sense, or we wouldn't have any grounds for a comprehensible discussion of whether it's a true or useful statement. (An example of a statement that makes no sense is "a scripting language is not purple".) I don't think this mooted "scripting" versus "programming" distinction is sustainable or productive, though, so I'm a bit puzzled why you found it necessary to tell me it isn't.
Even in your CL example: you are running a program ...does not matter if certain kinds of programs are impossible by design as it is not Turing complete.
Well, certainly it matters in some domains, since it determines whether certain computable functions can be implemented in that language. And "running a program" isn't a useful criterion, since it implies a circular definition (a programming language is one that can be used to create a program). But I agree it doesn't matter to the question of whether CL is a programming language.
Indeed, this was rather my point. There's a popular sentiment that HTML, say, is not a programming language, because it's not Turing-complete; I pointed out that there are languages which are intended for writing programs, and which practitioners recognize as programming languages, but which are also not TC. It's not the TC-nature of a language that makes it a programming language. In fact, as is generally the case with natural-language terms that are not well-defined as terms of art, whether something can be called a "programming language" ultimately comes down to whether your audience agrees with that use of the term.
All scripting languages are programming languages.
True by definition, I'd say, but there are scripting languages which are not Turing-complete and thus formally less powerful than what people usually consider "programming languages".
For example, CL (Control Language) on older versions of OS/400 had only one iteration construct: iterating over records in a file. And since file sizes were limited, every CL program is guaranteed to halt.[1]
That makes CL not-what-some-would-call-a-programming-language in a different sense than, say, a data-annotation language like HTML4 is.[2] Ultimately, I think, most people say HTML isn't a programming language because it's descriptive, while even CL is inherently imperative; it's a question of the modality you infer from the language.
But terms like "markup language", "scripting language", and "programming language", however common in the industry, aren't terms of art in software development or in computer science.[3] Traditionally (going back to the early decades of multiuser systems), "scripting language" was used for languages intended primarily for coordinating external components. The distinction has long-since blurred, and the terms are now used in broadly overlapping ways.
[1] And thus cannot be Turing-complete.
[2] HTML4 because HTML5 is forever a moving target, and who's to say WHAT-WG won't add full UTM capabilities to it tomorrow. And, yes, I know HTML5+CSS3 blah blah blah.
[3] In some cases they may be used as terms of art, of course, but then the authors are obliged to appeal to a particular definition. There's no broadly-accepted standard.
"Now"? They were suing left and right over things like their thumb wheel back when they were still Lawsuits In Motion. They've been litigation-happy since at least 2003, when they sued Xerox "defensively". They've been on the receiving end of many a patent dispute, too - and more than once lost a case. For a while there was an injunction forbidding them from selling Blackberry models in the US.
That wasn't the case for my previous mortgages, but underwriting has gotten much more strict in the US since 2008.
Obviously mirrors have failure modes as well. And generally speaking, more complexity means more failure modes, and often revenge effects as well.
(An example of a possible revenge effect with "virtual mirrors": Real side mirrors require the driver glance out the windows, which may lead to noticing something to the side that's not in the mirror's field of view. Screens won't require that, so drivers using them may miss hazards they otherwise would have noticed.)
The only sensible way to evaluate this change is with a well-conceived, fairly thorough threat model that looks at the likely failure modes, their consequences, and their probability. My guess is that if done well, "virtual mirrors" don't add that much risk, and largely compensate by reducing risk in other cases (e.g. low-light enhancement) - as long as the vehicle is decently maintained. But they'll be more prone to deterioration in old and unmaintained vehicles than mirrors are. Again, though, that's just a guess; it's all handwaving without a real threat model.
I'm far more interested in the question "Authorization from whom?".
(If you can't be pointlessly prescriptive about usage from "legal scholars", when can you be?)
To say nothing of the Top Gear dog! (And we may ask, was Top Gear Germany based on JKJ's "Three Men on the Bummel"?)
I agree, though, that the three-hosts arrangement was indispensable to the TG formula, along with the "Ambitious but Rubbish" DIY disasters and general amateurishness, both of which are certainly features of "Three Men on a Boat".