If you write complex code, where the flow path of one function can change the flow path of another function, then you get to multiply each of your tests by the number of other tests.
That's simply not true. As I've said, it's a problem that has been solved long time ago, you just never bothered to read up on the computer science side of CSE.
Yes, I know this makes no sense to you. Because you've never written a function that isn't self-contained, you've never enjoyed the benefits.
How on Earth would you come to this conclusion is beyond me. Duh, I have plenty of code where a bug in one function can affect the execution paths of tens or even hundreds of other functions. We all have such code. Break your string library for a good example of this magical "flow path of one function can change the flow path of another function", but to think this somehow makes it impossible to test your string library -- wow, just wow. You really seem to think it's all some complex magic, and that only you are doing a good job for your customer. Get off your high horse and get real. What you're saying so far is ultra silly.
If you can predict every combination of parameters relevant to the function, then your unit tests simply tell you when you broke your own function
If you seriously think you need to "predict" such stuff, then you need to go back to school. Guess what: there are ways of writing tests that are formally guaranteed to exercise every conditional in the source code, or, if you go deeper, every conditional in the assembly output of your compiler. Never mind people write and maintain such test suites as a matter of everyday work. It's only magic if you're clueless, you see.
oh come on, I assumed you knew how to build logic-based intelligence functions without a maze of if statements. it's never about a different flow path for each input type. it's about quick-converting any input type into a lesser or greater type to match the logic gate. a little bit of basic math takes those logic gates to incredible speeds.
Any compiler supporting classes and some notion of an interface will do that job for you. You've made, as we say in Polish, a pitchfork out of a needle. You're extolling handcrafting code for what the compiler should be doing for you, and you're under impression that tightly coupling a lone function to a bunch of different object classes is a good thing. Your posts are full of well-known antipatterns and I would not want anything to do with your code or your coding skills.
The claim
you're going to expect me to charge my client for the two hours of work that it's going to take to adapt a few megs of code throughout a project
is just silly: you're expected to do precisely the opposite, to implement an interface in a class that didn't implement it before, and be done with it. This is quite loosely coupled with any other code, so you won't be changing megabytes of anything.
you'll also, very quickly in my world, have more than three dozen isBlank() functions, all very similar, but completely different. And good luck to you. Humans consider blank to be blank, not a version of blank that's different than a different version of blank. It's called cognitive compression, and it allows for abstract thought.
You've got it so wrong I don't even know where to start. Blank is an adjective that has a loosely defined meaning. To every human it may mean something else, and that's what you don't want when dealing with formal systems such as software. When you're talking about data in a computer program, you must use at least a somewhat formal language when you specify what blank means; ideally we'd want a formal specification anyway, but most software engineers are not educated well enough for that (sigh). At that point reusing a common language adjective gives you very little, heck, it may mislead the user of such an API where everyone and their sister can be blak. An array is not blank, it's empty, just like a string is empty. A blank string, to me for example, may be full of blank characters. Ever heard of "fill in the blanks", huh? That's just one example of how misleading you are. You have no clue what cognitive compression is because it doesn't apply in the context of this discussion, not the way you're trying to frame it. In your sentence, you can replace "cognitive compression" with "wakalixes" and nothing of substance will be lost.
If you're not trolling then consider yourself so badly misinformed and so entrenched in poor software engineering practice as to be unemployable if anyone will ever link your resume to these posts somehow. Those posts are a big "don't hire me, please" sign. Yes, you can earn good salary as a consultant while being abhorrent, I've seen plenty of that. You're lucky the people who you work for are none the wiser.
I'd have thought that the tab-vs-space is a solved problem. It's not magic. Set your editor to match the source edited and bam, you're golden. People who still can't figure such a simple thing should be barred from programming.
Have you ever seen how JavaScript is used, you know, in the real world? The "scripting language used for selecting your state" was how it was used more than a decade ago. Ever been to Facebook or Google Maps and looked at their javascript? Good grief.
And herein lies the problem, but you somehow entirely missed it! In languages where the indentation doesn't matter, you have to potentially conflicting sources of structural information: indentation is obvious to the humans, but ignored by the compiler, whereas the brackets are easily missed by humans, but are the only thing that the compiler cares about. This is a source of obvious bugs. Why the heck have two ways of specifying the same thing, one that only works well for humans, the other that only works well for the compiler? Try reading non-indented code, the compiler has no problems though! The decision made in Python is that the information that's for humans will be used by the compiler, with no redundant and potentially conflicting syntax needed to specify the same thing. I personally adore that decision and consider it a good example of how a programming language can be designed for good usability by the programmer crowd. Yay!
It's reasonably streamlined in the U.S.. I hated the European bureaucracy of getting one. In Europe they almost universally always let you feel like they did you a big favor by finally letting you drive, and many people feel quite smug about themselves. Later they extol the virtues of such a system in spite of being treated like shit by the same. It's a phenomenon well known to psychology, apparently, can't bother with a link at the moment.
Braking is usually road friction limited in any modern car, including the Yaris. You slam the brakes, the ABS comes on, that's it. Taking about sports cars as if they were some implements of magic is unhelpful, unless you're claiming a $60k sports car can produce higher deceleration on braking, with ABS keeping the wheels turning, than a Yaris would -- in that case I'd like to see some measurements.
It's not an interpolation, please not redefine this fine word. What they do is merely taking the average velocity over a certain distance. The beauty of the average is that unless your instantaneous speed was equal to the average over the monitored distance (good luck with that), you're guaranteed to have been going both faster and slower than the average. So pray tell, how is that terrible math except that in most cases you get cited for a lower speed than your peak instantaneous velocity? It works in your favor!
They cut out a lot of the book for obvious reasons, and "adapted" some other things, but yes, I've enjoyed the movies. I'd say it's both required reading and watching, then. I've listened to the audiobook in the car. Listening to Pratchett's works always makes for a bit of a show when you're stopped at the red light and people watch you:)
Sorry, nobody has access to that, not even within the same country like USA. SpaceX had to learn for themselves. You won't exactly have a vendor with proven orbital launch technology tell their competitors what mistakes to avoid.
That 16 bit DOS thing probably wants an OHCI USB interface. Have you tried running it in vmware? It may just run. Vmware provides an emulated OHCI USB host. I'm still at loss why would anyone keep using such a hack. But anyway, it would not run under XP either...
I've come to install all dongle-requiring development environments in a dedicated virtual machine, that way they will be usable as long as we have to support the hardware the dev env is for -- it's usually 2-3x longer than support for any particular Windows version. Sometimes, I install the crack as well, and forget the whole dongle hassle. I've paid for the damn thing anyway, and there's just one copy of the vm running.
So you seem to be the armchair engineer who lives in a fairyland where non-general-purpose OSes don't have security holes. I have seen TCP/IP stacks that run on MCUs with 256kb of RAM have exploitable holes, so the fact that it runs on a tiny MCU doesn't mean it's automatically secure. You obviously only run software that has been formally proven to have no explotable security holes, and obviously have money for it. We who live in the real world, OTOH,...
Get some students to reverse engineer the heck out of it, get it running on linux, publicize your efforts, and scare the shit out of the vendor. Such endeavors mean that old hardware will be kept alive, cutting directly into their sales of new stuff. They will pay notice if they know their front end from their rear end; if they don't -- good for them anyway.
It's an interesting offshoot of the hardware abstraction layer and a particular OSS kernel development model. People were getting linux to work on those Sparcs, Alphas, and MIPSs, so they wrote drivers for the hardware. Those drivers would then, barring bugs, work on any machine with a PCI subsystem. Bugs could be fixed as there was source for them. The drivers did not need to bit rot if they were decently made. The ongoing maintenance was usually required to be done by whoever redid kernel infrastructure; they'd have then to fix all the drivers that got broken by, say, finer kernel locks, etc.
I think you're making it up or are misinformed. Can you do a strings dump on the supposed dos driver for that dongle and see who makes it? What are their system requirements?
If it's an industrial system that was put in use 5+ years ago, if it cost a couple thousand dollars to update it'd be considered cheap. If you factor in the cost of labor, you may be looking at a couple thousand dollars just to get an upgrade plan written. Of course the company has saved money on an in-house automation engineer and let him/her go long time ago, so it'll be a consulatant doing all that, and we're assuming that a competent and professional one will be found -- someone who won't rack up the hours just because they can.
I agree. Nobody in the industry wants to replace or tweak running PLCs unless really necessary, and the OS being out of supports rarely counts as being so. Properly designed, such systems always do have either an airgap or a well-maintained firewall+router. It's orders of magnitude cheaper to keep the firewall/router combo up to date. The competent techs who run such systems usually have hard disk images of every machine (they all fit on a USB stick nowadays), and should be able to restore the systems, should there be a breach, in pretty short order anyway -- if the breach is known, that is. Monitoring the logs on the firewall would usually give a clue that something is amiss, those systems normally don't start sending stuff out of the blue.
There's also another angle to the story: Windows XP Embedded is not normally meant to be updated, heck, the update service is IIRC disabled by default as usually such systems are meant either to be off internet or there to be only a well firewalled, normally closed maintenance VPN available between the PLCs and the maintenance PC. I would not put any embedded OS, not even linux, directly on internet without an intervening supported and maintained router/switch.
Good catch, I forgot to say I meant it per core (a core has up to 8 threads running on it). The "libraries" for SRAM are an overstatement, you need a dozen or two lines of XC for async sram, and maybe 2-3x that for synchronous one, even if you want it running in a separate thread and communicating via a channel with other threads. It's a good tutorial exercise, if one needs a tutorial that is.
You're free to use a 4-bit port for SRAM control, of course, and it'll be sufficient for async SRAM. For sync SRAM you can IIRC dedicate a 1-bit port for the clock if you want to use a timer to trigger moving data around, but that's not necessary if you can live with a tad lower performance, if that.
Admittedly my designs are often port-constrained, and on XS-1 there's a limited number of ports. Ports are logical resources that get allocated to physical pins at runtime. If you're brave, you can reallocate ports to different pins dynamically, but the tools essentially provide no support for that.
That's another aspect of XS-1 that's quite different from most other chips. The typical granularity offered by most MCUs is that you have a pin, and you can twiddle some bits to select which one of a fixed number of alternate functions gets assigned to it. On XS-1, each pin can be accessed from a set of ports (possibly of various output widths), and those pin-to-port assignments are dynamic. There's a machine code instruction to obtain a resource, such as a port, and you then use the handle thus obtained to operate on the port. The ports have built-in width conversion (a.k.a. serialization/deserialization), so if you have a port with, say, 4 bit output width, you can feed it 32 bits at a time. If you need some higher level functionality (timers, UARTS, PWMs, etc), you do it in software. Yet the software is loosely tied to timing of the events on the port. So, there's a static timing analyzer that can prove that your software is fast enough given timing constraints of your application! The analyzer uses the machine code, so it works whatever your source language was (C, C++, XC, assembly,...).
I didn't know that such a stupid thing even existed. One learns something new every day. I though that American mini-pedal emergency brake with locking ratchet was about as stupid as one could go (on many models it needs full engagement, usually followed by locked wheels, in order to release it).
Slashdot Mirror
If you write complex code, where the flow path of one function can change the flow path of another function, then you get to multiply each of your tests by the number of other tests.
That's simply not true. As I've said, it's a problem that has been solved long time ago, you just never bothered to read up on the computer science side of CSE.
Yes, I know this makes no sense to you. Because you've never written a function that isn't self-contained, you've never enjoyed the benefits.
How on Earth would you come to this conclusion is beyond me. Duh, I have plenty of code where a bug in one function can affect the execution paths of tens or even hundreds of other functions. We all have such code. Break your string library for a good example of this magical "flow path of one function can change the flow path of another function", but to think this somehow makes it impossible to test your string library -- wow, just wow. You really seem to think it's all some complex magic, and that only you are doing a good job for your customer. Get off your high horse and get real. What you're saying so far is ultra silly.
If you can predict every combination of parameters relevant to the function, then your unit tests simply tell you when you broke your own function
If you seriously think you need to "predict" such stuff, then you need to go back to school. Guess what: there are ways of writing tests that are formally guaranteed to exercise every conditional in the source code, or, if you go deeper, every conditional in the assembly output of your compiler. Never mind people write and maintain such test suites as a matter of everyday work. It's only magic if you're clueless, you see.
oh come on, I assumed you knew how to build logic-based intelligence functions without a maze of if statements. it's never about a different flow path for each input type. it's about quick-converting any input type into a lesser or greater type to match the logic gate. a little bit of basic math takes those logic gates to incredible speeds.
Any compiler supporting classes and some notion of an interface will do that job for you. You've made, as we say in Polish, a pitchfork out of a needle. You're extolling handcrafting code for what the compiler should be doing for you, and you're under impression that tightly coupling a lone function to a bunch of different object classes is a good thing. Your posts are full of well-known antipatterns and I would not want anything to do with your code or your coding skills.
The claim
you're going to expect me to charge my client for the two hours of work that it's going to take to adapt a few megs of code throughout a project
is just silly: you're expected to do precisely the opposite, to implement an interface in a class that didn't implement it before, and be done with it. This is quite loosely coupled with any other code, so you won't be changing megabytes of anything.
you'll also, very quickly in my world, have more than three dozen isBlank() functions, all very similar, but completely different. And good luck to you. Humans consider blank to be blank, not a version of blank that's different than a different version of blank. It's called cognitive compression, and it allows for abstract thought.
You've got it so wrong I don't even know where to start. Blank is an adjective that has a loosely defined meaning. To every human it may mean something else, and that's what you don't want when dealing with formal systems such as software. When you're talking about data in a computer program, you must use at least a somewhat formal language when you specify what blank means; ideally we'd want a formal specification anyway, but most software engineers are not educated well enough for that (sigh). At that point reusing a common language adjective gives you very little, heck, it may mislead the user of such an API where everyone and their sister can be blak. An array is not blank, it's empty, just like a string is empty. A blank string, to me for example, may be full of blank characters. Ever heard of "fill in the blanks", huh? That's just one example of how misleading you are. You have no clue what cognitive compression is because it doesn't apply in the context of this discussion, not the way you're trying to frame it. In your sentence, you can replace "cognitive compression" with "wakalixes" and nothing of substance will be lost.
If you're not trolling then consider yourself so badly misinformed and so entrenched in poor software engineering practice as to be unemployable if anyone will ever link your resume to these posts somehow. Those posts are a big "don't hire me, please" sign. Yes, you can earn good salary as a consultant while being abhorrent, I've seen plenty of that. You're lucky the people who you work for are none the wiser.
I'd have thought that the tab-vs-space is a solved problem. It's not magic. Set your editor to match the source edited and bam, you're golden. People who still can't figure such a simple thing should be barred from programming.
Read carefully. Not all of them are like that. Many of them are OEM and require bundling with any piece of PC hardware. A memory stick will do.
Have you ever seen how JavaScript is used, you know, in the real world? The "scripting language used for selecting your state" was how it was used more than a decade ago. Ever been to Facebook or Google Maps and looked at their javascript? Good grief.
And herein lies the problem, but you somehow entirely missed it! In languages where the indentation doesn't matter, you have to potentially conflicting sources of structural information: indentation is obvious to the humans, but ignored by the compiler, whereas the brackets are easily missed by humans, but are the only thing that the compiler cares about. This is a source of obvious bugs. Why the heck have two ways of specifying the same thing, one that only works well for humans, the other that only works well for the compiler? Try reading non-indented code, the compiler has no problems though! The decision made in Python is that the information that's for humans will be used by the compiler, with no redundant and potentially conflicting syntax needed to specify the same thing. I personally adore that decision and consider it a good example of how a programming language can be designed for good usability by the programmer crowd. Yay!
It's reasonably streamlined in the U.S.. I hated the European bureaucracy of getting one. In Europe they almost universally always let you feel like they did you a big favor by finally letting you drive, and many people feel quite smug about themselves. Later they extol the virtues of such a system in spite of being treated like shit by the same. It's a phenomenon well known to psychology, apparently, can't bother with a link at the moment.
Braking is usually road friction limited in any modern car, including the Yaris. You slam the brakes, the ABS comes on, that's it. Taking about sports cars as if they were some implements of magic is unhelpful, unless you're claiming a $60k sports car can produce higher deceleration on braking, with ABS keeping the wheels turning, than a Yaris would -- in that case I'd like to see some measurements.
It's not an interpolation, please not redefine this fine word. What they do is merely taking the average velocity over a certain distance. The beauty of the average is that unless your instantaneous speed was equal to the average over the monitored distance (good luck with that), you're guaranteed to have been going both faster and slower than the average. So pray tell, how is that terrible math except that in most cases you get cited for a lower speed than your peak instantaneous velocity? It works in your favor!
They cut out a lot of the book for obvious reasons, and "adapted" some other things, but yes, I've enjoyed the movies. I'd say it's both required reading and watching, then. I've listened to the audiobook in the car. Listening to Pratchett's works always makes for a bit of a show when you're stopped at the red light and people watch you :)
Going Postal by Terry Pratchett is required reading, then :)
Sorry, nobody has access to that, not even within the same country like USA. SpaceX had to learn for themselves. You won't exactly have a vendor with proven orbital launch technology tell their competitors what mistakes to avoid.
That 16 bit DOS thing probably wants an OHCI USB interface. Have you tried running it in vmware? It may just run. Vmware provides an emulated OHCI USB host. I'm still at loss why would anyone keep using such a hack. But anyway, it would not run under XP either...
I've come to install all dongle-requiring development environments in a dedicated virtual machine, that way they will be usable as long as we have to support the hardware the dev env is for -- it's usually 2-3x longer than support for any particular Windows version. Sometimes, I install the crack as well, and forget the whole dongle hassle. I've paid for the damn thing anyway, and there's just one copy of the vm running.
:)
So you seem to be the armchair engineer who lives in a fairyland where non-general-purpose OSes don't have security holes. I have seen TCP/IP stacks that run on MCUs with 256kb of RAM have exploitable holes, so the fact that it runs on a tiny MCU doesn't mean it's automatically secure. You obviously only run software that has been formally proven to have no explotable security holes, and obviously have money for it. We who live in the real world, OTOH, ...
Get some students to reverse engineer the heck out of it, get it running on linux, publicize your efforts, and scare the shit out of the vendor. Such endeavors mean that old hardware will be kept alive, cutting directly into their sales of new stuff. They will pay notice if they know their front end from their rear end; if they don't -- good for them anyway.
You are not serious, are you?
It's an interesting offshoot of the hardware abstraction layer and a particular OSS kernel development model. People were getting linux to work on those Sparcs, Alphas, and MIPSs, so they wrote drivers for the hardware. Those drivers would then, barring bugs, work on any machine with a PCI subsystem. Bugs could be fixed as there was source for them. The drivers did not need to bit rot if they were decently made. The ongoing maintenance was usually required to be done by whoever redid kernel infrastructure; they'd have then to fix all the drivers that got broken by, say, finer kernel locks, etc.
That's about right :)
I think you're making it up or are misinformed. Can you do a strings dump on the supposed dos driver for that dongle and see who makes it? What are their system requirements?
If it's an industrial system that was put in use 5+ years ago, if it cost a couple thousand dollars to update it'd be considered cheap. If you factor in the cost of labor, you may be looking at a couple thousand dollars just to get an upgrade plan written. Of course the company has saved money on an in-house automation engineer and let him/her go long time ago, so it'll be a consulatant doing all that, and we're assuming that a competent and professional one will be found -- someone who won't rack up the hours just because they can.
I agree. Nobody in the industry wants to replace or tweak running PLCs unless really necessary, and the OS being out of supports rarely counts as being so. Properly designed, such systems always do have either an airgap or a well-maintained firewall+router. It's orders of magnitude cheaper to keep the firewall/router combo up to date. The competent techs who run such systems usually have hard disk images of every machine (they all fit on a USB stick nowadays), and should be able to restore the systems, should there be a breach, in pretty short order anyway -- if the breach is known, that is. Monitoring the logs on the firewall would usually give a clue that something is amiss, those systems normally don't start sending stuff out of the blue.
There's also another angle to the story: Windows XP Embedded is not normally meant to be updated, heck, the update service is IIRC disabled by default as usually such systems are meant either to be off internet or there to be only a well firewalled, normally closed maintenance VPN available between the PLCs and the maintenance PC. I would not put any embedded OS, not even linux, directly on internet without an intervening supported and maintained router/switch.
Good catch, I forgot to say I meant it per core (a core has up to 8 threads running on it). The "libraries" for SRAM are an overstatement, you need a dozen or two lines of XC for async sram, and maybe 2-3x that for synchronous one, even if you want it running in a separate thread and communicating via a channel with other threads. It's a good tutorial exercise, if one needs a tutorial that is.
You're free to use a 4-bit port for SRAM control, of course, and it'll be sufficient for async SRAM. For sync SRAM you can IIRC dedicate a 1-bit port for the clock if you want to use a timer to trigger moving data around, but that's not necessary if you can live with a tad lower performance, if that.
Admittedly my designs are often port-constrained, and on XS-1 there's a limited number of ports. Ports are logical resources that get allocated to physical pins at runtime. If you're brave, you can reallocate ports to different pins dynamically, but the tools essentially provide no support for that.
That's another aspect of XS-1 that's quite different from most other chips. The typical granularity offered by most MCUs is that you have a pin, and you can twiddle some bits to select which one of a fixed number of alternate functions gets assigned to it. On XS-1, each pin can be accessed from a set of ports (possibly of various output widths), and those pin-to-port assignments are dynamic. There's a machine code instruction to obtain a resource, such as a port, and you then use the handle thus obtained to operate on the port. The ports have built-in width conversion (a.k.a. serialization/deserialization), so if you have a port with, say, 4 bit output width, you can feed it 32 bits at a time. If you need some higher level functionality (timers, UARTS, PWMs, etc), you do it in software. Yet the software is loosely tied to timing of the events on the port. So, there's a static timing analyzer that can prove that your software is fast enough given timing constraints of your application! The analyzer uses the machine code, so it works whatever your source language was (C, C++, XC, assembly, ...).
I didn't know that such a stupid thing even existed. One learns something new every day. I though that American mini-pedal emergency brake with locking ratchet was about as stupid as one could go (on many models it needs full engagement, usually followed by locked wheels, in order to release it).