'standard' NDA

On Friday, 4 October 2019 08:42:41 UTC+1, Clifford Heath wrote:
On 3/10/19 10:09 am, Clifford Heath wrote:

Most software is not "engineered" in any real sense (and for that matter
most "engineering" is not engineered either). Most "software engineers"
cannot adequately even define what they mean by "engineering".

My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources. So when a structural
engineer specifies a certain steel beam to support some load, they take
into account the specified load, the way the beam will be supported, and
the known properties of steel and of the type of beam specified.

The meaning of "properties of resources" in software is the properties
of storage devices, operating systems, databases, data structures and
the algorithms that implement operations on them. These properties are
almost only ever specified in the "happy path", and seldom if ever is
the worst-case behaviour specified. Instead, subsystems and libraries
are designed to avoid catastrophic worst cases (polynomial or
exponential runtimes, for example) - O(N*logN) is the worst that's
allowed without prior warning.

In any case software writers seldom know or consider these properties,
they just throw stuff at the wall and see what sticks. The same way the
structural engineer doesn't actually calculate the steel beam, they just
look it up in a table.

A former colleague trained first as a mech eng because he loved solving
the mathematical problems. During his first year working, he realised
that never in his career would he get to actually *use* the mathematical
analyses that he loved, so he went back to school and qualified in CS.
That's the kind of guy you want writing software for you (but they're
rare)!

So CS courses do actually teach the required analysis, and in my
experience software writers do have some awareness of it,  but only
enough to avoid using pathological algorithms. For the most part the
difficult algorithms are implemented in infrastructure code, and very
few people are competent to write that. (though many others try, and
they succeed only because spectacular computing power hides the
fundamental weakness of their code).

And then there's *systems* engineering, which is what happens when more
than one organisation works together to produce some system that's
larger than any of them could do by themselves. This brings in a raft of
human factors like clear communication, change management, etc. This too
can be engineered to some extent, but the vast majority of software
people never really find themselves in such a situation - and the Agile
movement is all about avoiding it. The one exceptional case is embedded
software, where you have a hardware team and a software team, and
neither can do what the other can. Our immaturity at systems engineering
explains the parlous state of embedded software.

I asked the dean of a big CS depertment what sort of programming they
teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

I *think* I understand that response. Modern CS is about *derivation*,
not about construction of step-by-step algorithms that perform some
derivation. By "derivation" I mean that for every current-state and
event there is an algebraic expression that derives next-state. This is
the basic idea behind functional programming. Every derivation is a
"function" that takes one parameter (current state) and by applying the
function, produces the next state. The compiler is responsible for
finding an algorithm to efficiently compute each function.

"Programming" then becomes the job of the compiler. The coder must find
a way to express their computation algebraically, and the compiler does
the rest. Haskell is perhaps the best examplar of this.

Clifford Heath.

John: You asked, I answered. It would be nice to get some feedback.

CH

A lot of engineering delivers non-guaranteed results. Look at almost any domestic electronics for examples.


NT
 
On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

No, there are plenty of times when even an excess of money won't
get people to do what you want.


You must be very stupid to think that engineers do not perform for
pay.

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

> Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

--
Regards,
Martin Brown
 
On Friday, 4 October 2019 03:51:36 UTC+1, Rick C wrote:
On Thursday, October 3, 2019 at 9:24:19 PM UTC-4, tabby wrote:
On Thursday, 3 October 2019 20:21:53 UTC+1, John Larkin wrote:

It's hard to see how any engineer (or politician) can function without
some basic instincts for control theory. I see people having crazy
ideas of causality all the time. They have no notion of what feedback
can do.

Do something. Things get worse. So do more of it.

The day politicians understand what they're screwing with will be a very different world.

You do understand that politicians are created by the voters, no?

It's not that simple. Political views & policies are the result of idea development by both politicians and non-politicians, often more than one source & stage of input there.


It's like a twilight story where the person gets three wishes from the genie and each one turns out poorly because he didn't think it through. Then people want to blame the genie.

So when you badmouth politicians, you are badmouthing yourself.

Get real!

You should. Blaming me or any one nonpolitician for all politicians' shenanigans is beyond silly.

A major problem generally with politicians is that too often they don't really understand what they're making policies on.


NT
 
On Friday, 4 October 2019 09:35:15 UTC+1, Martin Brown wrote:
On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

Tesla was some of both

Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

Skyscrapers primarily depend on lifts/elevators, which IIRC are a problem solved by Otis.

AC would have taken over without Tesla, though it would have taken longer & cost more to convert.


NT
 
On Friday, 4 October 2019 10:59:38 UTC+1, Clifford Heath wrote:
On 4/10/19 6:21 pm, tabbypurr wrote:
On Friday, 4 October 2019 08:42:41 UTC+1, Clifford Heath wrote:
On 3/10/19 10:09 am, Clifford Heath wrote:

Most software is not "engineered" in any real sense (and for that matter
most "engineering" is not engineered either). Most "software engineers"
cannot adequately even define what they mean by "engineering".

My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources. So when a structural
engineer specifies a certain steel beam to support some load, they take
into account the specified load, the way the beam will be supported, and
the known properties of steel and of the type of beam specified.

The meaning of "properties of resources" in software is the properties
of storage devices, operating systems, databases, data structures and
the algorithms that implement operations on them. These properties are
almost only ever specified in the "happy path", and seldom if ever is
the worst-case behaviour specified. Instead, subsystems and libraries
are designed to avoid catastrophic worst cases (polynomial or
exponential runtimes, for example) - O(N*logN) is the worst that's
allowed without prior warning.

In any case software writers seldom know or consider these properties,
they just throw stuff at the wall and see what sticks. The same way the
structural engineer doesn't actually calculate the steel beam, they just
look it up in a table.

A former colleague trained first as a mech eng because he loved solving
the mathematical problems. During his first year working, he realised
that never in his career would he get to actually *use* the mathematical
analyses that he loved, so he went back to school and qualified in CS..
That's the kind of guy you want writing software for you (but they're
rare)!

So CS courses do actually teach the required analysis, and in my
experience software writers do have some awareness of it,  but only
enough to avoid using pathological algorithms. For the most part the
difficult algorithms are implemented in infrastructure code, and very
few people are competent to write that. (though many others try, and
they succeed only because spectacular computing power hides the
fundamental weakness of their code).

And then there's *systems* engineering, which is what happens when more
than one organisation works together to produce some system that's
larger than any of them could do by themselves. This brings in a raft of
human factors like clear communication, change management, etc. This too
can be engineered to some extent, but the vast majority of software
people never really find themselves in such a situation - and the Agile
movement is all about avoiding it. The one exceptional case is embedded
software, where you have a hardware team and a software team, and
neither can do what the other can. Our immaturity at systems engineering
explains the parlous state of embedded software.

I asked the dean of a big CS depertment what sort of programming they
teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

I *think* I understand that response. Modern CS is about *derivation*,
not about construction of step-by-step algorithms that perform some
derivation. By "derivation" I mean that for every current-state and
event there is an algebraic expression that derives next-state. This is
the basic idea behind functional programming. Every derivation is a
"function" that takes one parameter (current state) and by applying the
function, produces the next state. The compiler is responsible for
finding an algorithm to efficiently compute each function.

"Programming" then becomes the job of the compiler. The coder must find
a way to express their computation algebraically, and the compiler does
the rest. Haskell is perhaps the best examplar of this.

Clifford Heath.

John: You asked, I answered. It would be nice to get some feedback.

CH

A lot of engineering delivers non-guaranteed results. Look at almost any domestic electronics for examples.

In mass-market products the engineer doesn't set the goals. The
bean-counters do that, and the engineers have to design to guarantee the
business goals by making cost/MTBF calculations. It's still engineering.

CH

Exactly. Meeting business goals does not always equal guaranteeing the thing works. It just has to sell and not have too many duds be returned.


NT
 
On 4/10/19 6:21 pm, tabbypurr@gmail.com wrote:
On Friday, 4 October 2019 08:42:41 UTC+1, Clifford Heath wrote:
On 3/10/19 10:09 am, Clifford Heath wrote:

Most software is not "engineered" in any real sense (and for that matter
most "engineering" is not engineered either). Most "software engineers"
cannot adequately even define what they mean by "engineering".

My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources. So when a structural
engineer specifies a certain steel beam to support some load, they take
into account the specified load, the way the beam will be supported, and
the known properties of steel and of the type of beam specified.

The meaning of "properties of resources" in software is the properties
of storage devices, operating systems, databases, data structures and
the algorithms that implement operations on them. These properties are
almost only ever specified in the "happy path", and seldom if ever is
the worst-case behaviour specified. Instead, subsystems and libraries
are designed to avoid catastrophic worst cases (polynomial or
exponential runtimes, for example) - O(N*logN) is the worst that's
allowed without prior warning.

In any case software writers seldom know or consider these properties,
they just throw stuff at the wall and see what sticks. The same way the
structural engineer doesn't actually calculate the steel beam, they just
look it up in a table.

A former colleague trained first as a mech eng because he loved solving
the mathematical problems. During his first year working, he realised
that never in his career would he get to actually *use* the mathematical
analyses that he loved, so he went back to school and qualified in CS.
That's the kind of guy you want writing software for you (but they're
rare)!

So CS courses do actually teach the required analysis, and in my
experience software writers do have some awareness of it,  but only
enough to avoid using pathological algorithms. For the most part the
difficult algorithms are implemented in infrastructure code, and very
few people are competent to write that. (though many others try, and
they succeed only because spectacular computing power hides the
fundamental weakness of their code).

And then there's *systems* engineering, which is what happens when more
than one organisation works together to produce some system that's
larger than any of them could do by themselves. This brings in a raft of
human factors like clear communication, change management, etc. This too
can be engineered to some extent, but the vast majority of software
people never really find themselves in such a situation - and the Agile
movement is all about avoiding it. The one exceptional case is embedded
software, where you have a hardware team and a software team, and
neither can do what the other can. Our immaturity at systems engineering
explains the parlous state of embedded software.

I asked the dean of a big CS depertment what sort of programming they
teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

I *think* I understand that response. Modern CS is about *derivation*,
not about construction of step-by-step algorithms that perform some
derivation. By "derivation" I mean that for every current-state and
event there is an algebraic expression that derives next-state. This is
the basic idea behind functional programming. Every derivation is a
"function" that takes one parameter (current state) and by applying the
function, produces the next state. The compiler is responsible for
finding an algorithm to efficiently compute each function.

"Programming" then becomes the job of the compiler. The coder must find
a way to express their computation algebraically, and the compiler does
the rest. Haskell is perhaps the best examplar of this.

Clifford Heath.

John: You asked, I answered. It would be nice to get some feedback.

CH

A lot of engineering delivers non-guaranteed results. Look at almost any domestic electronics for examples.

In mass-market products the engineer doesn't set the goals. The
bean-counters do that, and the engineers have to design to guarantee the
business goals by making cost/MTBF calculations. It's still engineering.

CH
 
tabbypurr@gmail.com wrote in
news:1372fb53-bb25-4c17-9035-fd93c9824cbb@googlegroups.com:

On Friday, 4 October 2019 09:35:15 UTC+1, Martin Brown wrote:
On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with
his greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

Tesla was some of both

And you are a lot of neither. You are simply an abject idiot.
Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

Skyscrapers primarily depend on lifts/elevators, which IIRC are a
problem solved by Otis.

AC would have taken over without Tesla,

You are truly dumber than dogshit.

though it would have taken
longer & cost more to convert.

You are an absolute idiot. An example of how commiting non-vetted
'news' into your brain and mindset as being fact.

You broke yourself, boy. And that was decades ago.
 
Martin Brown <'''newspam'''@nezumi.demon.co.uk> wrote in news:qn707u
$ica$1@gioia.aioe.org:

On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

No, there are plenty of times when even an excess of money won't
get people to do what you want.


You must be very stupid to think that engineers do not perform
for
pay.

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

He is an abject idiot to have been so easily trapped into his
stupidity by my example.
 
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:94d794d0-b42f-47b9-8a7b-2055b5515039@googlegroups.com:

On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

No, there are plenty of times when even an excess of money
won't get people to do what you want.


You must be very stupid to think that engineers do not perform
for
pay.

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

Good example.

You are not very bright. Funny how I knew you would reply in such
a stupid manner. Did you get all that from your google hunt, child?
The point was that despite not being in lock step with his employer,
he still performed the work. Their disputes over technology were the
result of discusssion WHILE Tesla was doing the tasks Edison hired
him to do.

You are really one stupid dopey old fuck, putz.

Where do you think the power that keeps your laptop charged (or that
allowed you to do the google hunt)or your phone and that powers your
coffee pot and your PC comes from?

You are truly about as fucking stupid as it gets. Don't worry
though... we have a president in office (for now) competing with you
and the other idiots in the nation that voted for him for that grade.
But you are right up there on the stupid index.
 
On 4/10/19 8:19 pm, tabbypurr@gmail.com wrote:
On Friday, 4 October 2019 10:59:38 UTC+1, Clifford Heath wrote:
On 4/10/19 6:21 pm, tabbypurr wrote:
On Friday, 4 October 2019 08:42:41 UTC+1, Clifford Heath wrote:
On 3/10/19 10:09 am, Clifford Heath wrote:
My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources.
A lot of engineering delivers non-guaranteed results. Look at almost any domestic electronics for examples.
In mass-market products the engineer doesn't set the goals. The
bean-counters do that, and the engineers have to design to guarantee the
business goals by making cost/MTBF calculations. It's still engineering.
Exactly. Meeting business goals does not always equal guaranteeing the thing works. It just has to sell and not have too many duds be returned.

What part of "guarantee that certain outcomes will always be met" was
ambiguous to you? I never said that the things would always *work*,
those were your words.

CH
 
On Fri, 4 Oct 2019 17:42:35 +1000, Clifford Heath <no.spam@please.net>
wrote:

On 3/10/19 10:09 am, Clifford Heath wrote:
On 3/10/19 8:55 am, John Larkin wrote:
On Wed, 2 Oct 2019 17:22:50 -0400, bitrex <user@example.net> wrote:
software engineering and electrical engineering have diverged very far
over time to the point that outside a basic circuits class some students
take.

They should teach EE students the fundamentals, as always. Physics,
electromagnetics, circuit theory, EDA (engineering unit concepts),
signals+systems, control theory. Without that background, anything
more "advanced" is useless.

I have no idea what software engineering is. I should buy a textbook.
I did buy a sociology textbook; it was hilarious.

Can anybody recommend a good (or at least popular) undergrad intro
textbook in software engineering?

Most software is not "engineered" in any real sense (and for that matter
most "engineering" is not engineered either). Most "software engineers"
cannot adequately even define what they mean by "engineering".

My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources. So when a structural
engineer specifies a certain steel beam to support some load, they take
into account the specified load, the way the beam will be supported, and
the known properties of steel and of the type of beam specified.

The meaning of "properties of resources" in software is the properties
of storage devices, operating systems, databases, data structures and
the algorithms that implement operations on them. These properties are
almost only ever specified in the "happy path", and seldom if ever is
the worst-case behaviour specified. Instead, subsystems and libraries
are designed to avoid catastrophic worst cases (polynomial or
exponential runtimes, for example) - O(N*logN) is the worst that's
allowed without prior warning.

In any case software writers seldom know or consider these properties,
they just throw stuff at the wall and see what sticks. The same way the
structural engineer doesn't actually calculate the steel beam, they just
look it up in a table.

A former colleague trained first as a mech eng because he loved solving
the mathematical problems. During his first year working, he realised
that never in his career would he get to actually *use* the mathematical
analyses that he loved, so he went back to school and qualified in CS.
That's the kind of guy you want writing software for you (but they're
rare)!

So CS courses do actually teach the required analysis, and in my
experience software writers do have some awareness of it,  but only
enough to avoid using pathological algorithms. For the most part the
difficult algorithms are implemented in infrastructure code, and very
few people are competent to write that. (though many others try, and
they succeed only because spectacular computing power hides the
fundamental weakness of their code).

And then there's *systems* engineering, which is what happens when more
than one organisation works together to produce some system that's
larger than any of them could do by themselves. This brings in a raft of
human factors like clear communication, change management, etc. This too
can be engineered to some extent, but the vast majority of software
people never really find themselves in such a situation - and the Agile
movement is all about avoiding it. The one exceptional case is embedded
software, where you have a hardware team and a software team, and
neither can do what the other can. Our immaturity at systems engineering
explains the parlous state of embedded software.

I asked the dean of a big CS depertment what sort of programming they
teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

I *think* I understand that response. Modern CS is about *derivation*,
not about construction of step-by-step algorithms that perform some
derivation. By "derivation" I mean that for every current-state and
event there is an algebraic expression that derives next-state. This is
the basic idea behind functional programming. Every derivation is a
"function" that takes one parameter (current state) and by applying the
function, produces the next state. The compiler is responsible for
finding an algorithm to efficiently compute each function.

"Programming" then becomes the job of the compiler. The coder must find
a way to express their computation algebraically, and the compiler does
the rest. Haskell is perhaps the best examplar of this.

Clifford Heath.

John: You asked, I answered. It would be nice to get some feedback.

CH

What do you mean by "guarantee that certain outcomes will always be
met" ? There is always risk, always bugs. We always take chances, and
if we try too hard to eliminate risk we'll never get stuff done.

I avoid designing stuff that, if it fails, will blow expensive things
up or kill people.

Programming is a lot more than algebra and algorithms. I don't think
the average programmer even knows how to do algebra. The real problem
in programming is to control procedural flow and synchronize events
and avoid idiotic pointer and buffer crashes.

Computer Science doesn't seem to have much interest in computers.
Dijkstra famously said that he didn't have regular access to a
computer.

I think the average programmer has never heard of a state machine,
either.

I don't like compilers in general. All my production code was in
assembler.

Python looks OK. I should get into that one day.








--

John Larkin Highland Technology, Inc

lunatic fringe electronics
 
On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown wrote:
On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

No, there are plenty of times when even an excess of money won't
get people to do what you want.


You must be very stupid to think that engineers do not perform for
pay.

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

Tesla was going to be Tesla, Edison was going to be Edison. George Westinghouse, I think, is the most important person in AC power. He could have walked away and still been rich. In my understanding of him he pursued it because he knew it was right , but not obviously profitable to go up against Edison. Westinghouse is regarded as one of the best people in the era of big industrialists. (Hershy was pretty good too, something about Pennsylvania I guess).


--
Regards,
Martin Brown
 
On 04/10/19 16:32, jlarkin@highlandsniptechnology.com wrote:
I think the average programmer has never heard of a state machine,
either.

Someone maintaining FSMs in a telecom application: "Aren't FSMs
something in a compiler's parsers?" Grrr.


I don't like compilers in general. All my production code was in
assembler.

The language is key; some make compilation easy and
predictable without rolling in the mud with language
lawyers. Other languages don't.


> Python looks OK. I should get into that one day.

Cut and paste some code and get the indentation subtly
wrong. In Python there can be no option to "reformat and
pretty print this arbitrary blob of code".

Be aware of the consequences of the Global Interpreter Lock.

Apart from that, Python is OK. The main attraction is the
wealth of libraries of code that I have no interest in
developing.
 
On Wednesday, October 2, 2019 at 4:58:04 PM UTC-4, John Larkin wrote:
On Wed, 2 Oct 2019 14:02:07 -0400, bitrex <user@example.net> wrote:

On 10/2/19 1:59 PM, bitrex wrote:
On 10/2/19 1:49 PM, John Larkin wrote:
On Tue, 1 Oct 2019 17:55:09 -0700 (PDT), George Herold
gherold@teachspin.com> wrote:

John (Larkin), You offered to send me a 'standard' NDA.  I wanted to
take you up on that.  Maybe on dropbox?  Or my email (now) is
ggherold@gmail.com

Thanks
George H.

Here is our starting-point NDA.

https://www.dropbox.com/s/b924j4e9jbbven2/NDA%20Draft%20-2%20.docx?dl=0

This has been mangled by multiple lawyers, and other companies usually
sign this, sometimes with minor revs. It's pretty much the standard
Silicon Valley NDA.

We have had some legal doings with a giant company who signed this
basic form when they needed stuff badly. They later discovered that we
take it seriously.

One trick companies will do is to sign the NDA, let you do a lot of
work for them, show them how it's done, and then do a big prior-art
search to justify stealing the designs. I could name names. About all
you can do then is walk away and concentrate on working with people
who have ethics.

It happens and unless the job is heading towards mid five figures
there's not much to do but write it off. I rarely have any work that
pays that much so far. :(

Clue: if their engineers look eager to do it themselves, they probably
will.


In the 21st century there are online avenues both for contract
work/employment and for just contracting to do tutoring/general
education. If someone seems super-eager to do it themselves then there
is no reason not to just acknowledge that and re-direct to the proper
department, they often accept.

You can charge hourly for just talking, which while perhaps not quite as
well-paid or as emotionally satisfying as designing something, is pretty
easy money. Sometimes they decide they'd rather you do something once
they fully realize it's beyond them so it turns out into being an
elongated pitch session, but you get paid for it.

PID controllers are apparently a hot area of interest and there are
software guys who will pay just to talk with someone who seems like
they've successfully implemented one.

Nobody teaches control theory in college any more? I guess the
software guys don't learn things like that. I'm not sure what they do
learn.

I just had to explain to a guy at a biggish aircraft outfit how
synchros and resolvers and LVDTs work. He had no idea.

Yes they do and it depends what university and who teaches it.
I have taken and taught control courses that are basically all "math" and because we taught both classical and modern control theory in the same course, there was no time to go into a lot of the different types of devices. We usually picked one or two types and ran with that through the course.
This type of course was at a university where theory and math foundations were emphasized over actuality. Most of the labs were based on matlab and simulink models.
I've also seen control courses taught by people who never implemented a system in an industrial setting. Most of their stuff was done in a scaled down lab where they may have been exposed to pieces n parts of robots of one sort or another. My intro to control theory (set wayback machine to 1970s) was taught by a fellow from industry.

At another university the controls course was basically all classical theory with more of an emphasis on applications and usage of real devices. While we used matlab and simulink models, we applied the controllers to HIL labs where real devices were used. Students learned the difference between ideal math models, more detailed math models, and realities of real devices.

In one syllabus I was forced to use, a PID controller was never discussed formally. I gave it out as extra credit reading and analysis.
In another course, after learning about first and second order DE's we taught the basics of PID controllers and what happens when controllers are implemented digitally. I taught the standard root locus, pole placement techniques, etc. of classical control.

So the answer to your question is 'it depends'...
Unless you take courses in 'embedded systems' one hardly ever sees real devices.
In my experience, 'software types' out of college have no clue about realities and rely on tutoring by someone else - unless it is a stove piped type of org in which case, a spec is thrown over the wall with instructions to 'program this module'....and off they go. I've seen sooo many problems cause by this over the years and it still continues.
J
 
On Wednesday, October 2, 2019 at 2:02:14 PM UTC-4, bitrex wrote:
On 10/2/19 1:59 PM, bitrex wrote:
On 10/2/19 1:49 PM, John Larkin wrote:
On Tue, 1 Oct 2019 17:55:09 -0700 (PDT), George Herold
gherold@teachspin.com> wrote:

John (Larkin), You offered to send me a 'standard' NDA.  I wanted to
take you up on that.  Maybe on dropbox?  Or my email (now) is
ggherold@gmail.com

Thanks
George H.

Here is our starting-point NDA.

https://www.dropbox.com/s/b924j4e9jbbven2/NDA%20Draft%20-2%20.docx?dl=0

This has been mangled by multiple lawyers, and other companies usually
sign this, sometimes with minor revs. It's pretty much the standard
Silicon Valley NDA.

We have had some legal doings with a giant company who signed this
basic form when they needed stuff badly. They later discovered that we
take it seriously.

One trick companies will do is to sign the NDA, let you do a lot of
work for them, show them how it's done, and then do a big prior-art
search to justify stealing the designs. I could name names. About all
you can do then is walk away and concentrate on working with people
who have ethics.

It happens and unless the job is heading towards mid five figures
there's not much to do but write it off. I rarely have any work that
pays that much so far. :(

Clue: if their engineers look eager to do it themselves, they probably
will.


In the 21st century there are online avenues both for contract
work/employment and for just contracting to do tutoring/general
education. If someone seems super-eager to do it themselves then there
is no reason not to just acknowledge that and re-direct to the proper
department, they often accept.

You can charge hourly for just talking, which while perhaps not quite as
well-paid or as emotionally satisfying as designing something, is pretty
easy money. Sometimes they decide they'd rather you do something once
they fully realize it's beyond them so it turns out into being an
elongated pitch session, but you get paid for it.

PID controllers are apparently a hot area of interest and there are
software guys who will pay just to talk with someone who seems like
they've successfully implemented one.

Really??? I'll throw my hat in the ring. Successfully eh? I bet they got tripped up by the issues associated with discretization of an analog model.. Yes, numbers in digital computers can and do roll over causing amusing results when integral windup all of a sudden becomes negative. Then there is always the sampling time jitter caused by numerous task scheduling and badly done scheduling analysis. Oh, we'll just throw a few digital filters at it...that just made it worse....lol yes, Nyquist criteria must be paid attention to....
 
On Fri, 4 Oct 2019 12:19:48 -0700 (PDT), jjhudak4@gmail.com wrote:

On Wednesday, October 2, 2019 at 2:02:14 PM UTC-4, bitrex wrote:
On 10/2/19 1:59 PM, bitrex wrote:
On 10/2/19 1:49 PM, John Larkin wrote:
On Tue, 1 Oct 2019 17:55:09 -0700 (PDT), George Herold
gherold@teachspin.com> wrote:

John (Larkin), You offered to send me a 'standard' NDA.  I wanted to
take you up on that.  Maybe on dropbox?  Or my email (now) is
ggherold@gmail.com

Thanks
George H.

Here is our starting-point NDA.

https://www.dropbox.com/s/b924j4e9jbbven2/NDA%20Draft%20-2%20.docx?dl=0

This has been mangled by multiple lawyers, and other companies usually
sign this, sometimes with minor revs. It's pretty much the standard
Silicon Valley NDA.

We have had some legal doings with a giant company who signed this
basic form when they needed stuff badly. They later discovered that we
take it seriously.

One trick companies will do is to sign the NDA, let you do a lot of
work for them, show them how it's done, and then do a big prior-art
search to justify stealing the designs. I could name names. About all
you can do then is walk away and concentrate on working with people
who have ethics.

It happens and unless the job is heading towards mid five figures
there's not much to do but write it off. I rarely have any work that
pays that much so far. :(

Clue: if their engineers look eager to do it themselves, they probably
will.


In the 21st century there are online avenues both for contract
work/employment and for just contracting to do tutoring/general
education. If someone seems super-eager to do it themselves then there
is no reason not to just acknowledge that and re-direct to the proper
department, they often accept.

You can charge hourly for just talking, which while perhaps not quite as
well-paid or as emotionally satisfying as designing something, is pretty
easy money. Sometimes they decide they'd rather you do something once
they fully realize it's beyond them so it turns out into being an
elongated pitch session, but you get paid for it.

PID controllers are apparently a hot area of interest and there are
software guys who will pay just to talk with someone who seems like
they've successfully implemented one.

Really??? I'll throw my hat in the ring. Successfully eh? I bet they got tripped up by the issues associated with discretization of an analog model. Yes, numbers in digital computers can and do roll over causing amusing results when integral windup all of a sudden becomes negative. Then there is always the sampling time jitter caused by numerous task scheduling and badly done scheduling analysis. Oh, we'll just throw a few digital filters at it...that just made it worse....lol yes, Nyquist criteria must be paid attention to....

There are a few fun corner cases: bumpless transfer, slew windup,
various bits saturating, nonlinearities, things like that.

The "d" part of PID is usually bad news.
 
On Friday, October 4, 2019 at 4:19:24 AM UTC-4, tabb...@gmail.com wrote:
On Friday, 4 October 2019 03:51:36 UTC+1, Rick C wrote:
On Thursday, October 3, 2019 at 9:24:19 PM UTC-4, tabby wrote:
On Thursday, 3 October 2019 20:21:53 UTC+1, John Larkin wrote:

It's hard to see how any engineer (or politician) can function without
some basic instincts for control theory. I see people having crazy
ideas of causality all the time. They have no notion of what feedback
can do.

Do something. Things get worse. So do more of it.

The day politicians understand what they're screwing with will be a very different world.

You do understand that politicians are created by the voters, no?

It's not that simple. Political views & policies are the result of idea development by both politicians and non-politicians, often more than one source & stage of input there.

It is *exactly* that simple because the politicians are selected by the voters. So no one has anyone to blame but themselves for voting without thinking.


It's like a twilight story where the person gets three wishes from the genie and each one turns out poorly because he didn't think it through. Then people want to blame the genie.

So when you badmouth politicians, you are badmouthing yourself.

Get real!

You should. Blaming me or any one nonpolitician for all politicians' shenanigans is beyond silly.

Not just you, all voters. That's what a democracy is, run by the voters. You can say we vote for someone else to do the job, but that's like saying you couldn't do anything about the crappy way your lawn mowing service mows your lawn. YOU selected them and YOU keep selecting the same ones.

Your argument is just a way of avoiding responsibility for being a CRAPPY VOTER and not doing YOUR JOB!


> A major problem generally with politicians is that too often they don't really understand what they're making policies on.

LOL! But we keep electing the same ignoramuses?

--

Rick C.

---+ Get 2,000 miles of free Supercharging
---+ Tesla referral code - https://ts.la/richard11209
 
On Friday, October 4, 2019 at 4:31:39 AM UTC-4, Martin Brown wrote:
On 04/10/2019 03:51, Rick C wrote:
On Thursday, October 3, 2019 at 9:24:19 PM UTC-4, tabb...@gmail.com
wrote:
On Thursday, 3 October 2019 20:21:53 UTC+1, John Larkin wrote:

It's hard to see how any engineer (or politician) can function
without some basic instincts for control theory. I see people
having crazy ideas of causality all the time. They have no notion
of what feedback can do.

Do something. Things get worse. So do more of it.

The day politicians understand what they're screwing with will be a
very different world.

You do understand that politicians are created by the voters, no?

The fundamental problem is that politicians are self selected as people
who want to be in the public eye and are very good at getting elected.
That does not qualify them to make sensible decisions.

Yes, the voters are helpless against the people "who want to be in the public eye". How could we ever resist their charms???

By not being idiots and letting every smooth talking flim-flam man talk us out of our life savings or worse.

If someone complained he didn't like the way his car chewed up tires even though there were numerous law suits about it when he bought his car, he would be skewered for not checking into the car before he bought.

But politician are exempt from getting any real scrutiny other than what the press might dig up which is more about ratings than information.


It's like a twilight story where the person gets three wishes from
the genie and each one turns out poorly because he didn't think it
through. Then people want to blame the genie.

So when you badmouth politicians, you are badmouthing yourself.

The snag with democracy is that it is predicated on people making
*informed* decisions understanding the consequences of their choices.

Brexit is a perfect example of what happens when you hold a referendum
on an issue so complex that only a small proportion of the population
can understand the issues. The result is people vote on gut instinct and
follow populist demagogues like Farage, Trump and now Johnson.

For every complex problem there is an obvious simple *WRONG* answer.

This isn't about an issue. This is about selecting politicians who have a history of proper guidance. But the same rules apply. Because people don't want to be bothered with thinking, they let the politicians use advertising to promote "messages" that make us feel good or bad (depending on whether they are talking about themselves or others). We govern our governors by our feelings, not our heads.


Get real!

Not all politicians are self serving grasping lying toerags but enough
of them are to give the decent ones a bad name. Guilt by association.

It's not hard to tell who is who.


America famously has the best politicians that money can buy. They start
fund raising for their next election immediately after getting elected
and spend obscene amounts of money on big political campaigns.

Yep, the laws need to be changed, but we have the Supreme Court working against us.

--

Rick C.

--+- Get 2,000 miles of free Supercharging
--+- Tesla referral code - https://ts.la/richard11209
 
On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown wrote:
On 04/10/2019 08:00, Rick C wrote:
On Thursday, October 3, 2019 at 11:50:18 PM UTC-4,
DecadentLinux...@decadence.org wrote:
Rick C <gnuarm.deletethisbit@gmail.com> wrote in
news:ee230361-575f-4952-b921-7568e47f02e6@googlegroups.com:

No, there are plenty of times when even an excess of money won't
get people to do what you want.


You must be very stupid to think that engineers do not perform for
pay.

Ask Nikola Tesla. He worked for Thomas Edison.

I seem to recall that ended very badly for him, broke and with his
greatest projects in ruin. A real nut job by all accounts.

It can be a very fine line between true genius and madness.

Good example.

Never the less we do not use Edison's DC electric supply today.
Edison was incredibly good at self publicity.

Without Tesla there would be no skyscrapers. AC electricity and
transformers allow much more effective power transmission.

Obviously you've never heard of a little company called Westinghouse.

--

Rick C.

--++ Get 2,000 miles of free Supercharging
--++ Tesla referral code - https://ts.la/richard11209
 
On Friday, October 4, 2019 at 6:19:27 AM UTC-4, tabb...@gmail.com wrote:
On Friday, 4 October 2019 10:59:38 UTC+1, Clifford Heath wrote:
On 4/10/19 6:21 pm, tabbypurr wrote:
On Friday, 4 October 2019 08:42:41 UTC+1, Clifford Heath wrote:
On 3/10/19 10:09 am, Clifford Heath wrote:

Most software is not "engineered" in any real sense (and for that matter
most "engineering" is not engineered either). Most "software engineers"
cannot adequately even define what they mean by "engineering".

My definition: engineering is solving problems by applying known
(measured) properties of available resources in a way that provides a
guarantee that certain outcomes will always be met, despite any natural
variation in the properties of those resources. So when a structural
engineer specifies a certain steel beam to support some load, they take
into account the specified load, the way the beam will be supported, and
the known properties of steel and of the type of beam specified.

The meaning of "properties of resources" in software is the properties
of storage devices, operating systems, databases, data structures and
the algorithms that implement operations on them. These properties are
almost only ever specified in the "happy path", and seldom if ever is
the worst-case behaviour specified. Instead, subsystems and libraries
are designed to avoid catastrophic worst cases (polynomial or
exponential runtimes, for example) - O(N*logN) is the worst that's
allowed without prior warning.

In any case software writers seldom know or consider these properties,
they just throw stuff at the wall and see what sticks. The same way the
structural engineer doesn't actually calculate the steel beam, they just
look it up in a table.

A former colleague trained first as a mech eng because he loved solving
the mathematical problems. During his first year working, he realised
that never in his career would he get to actually *use* the mathematical
analyses that he loved, so he went back to school and qualified in CS.
That's the kind of guy you want writing software for you (but they're
rare)!

So CS courses do actually teach the required analysis, and in my
experience software writers do have some awareness of it,  but only
enough to avoid using pathological algorithms. For the most part the
difficult algorithms are implemented in infrastructure code, and very
few people are competent to write that. (though many others try, and
they succeed only because spectacular computing power hides the
fundamental weakness of their code).

And then there's *systems* engineering, which is what happens when more
than one organisation works together to produce some system that's
larger than any of them could do by themselves. This brings in a raft of
human factors like clear communication, change management, etc. This too
can be engineered to some extent, but the vast majority of software
people never really find themselves in such a situation - and the Agile
movement is all about avoiding it. The one exceptional case is embedded
software, where you have a hardware team and a software team, and
neither can do what the other can. Our immaturity at systems engineering
explains the parlous state of embedded software.

I asked the dean of a big CS depertment what sort of programming they
teach nowadays. She handed me my head. "We don't teach programming!"

Oh. Sorry.

I *think* I understand that response. Modern CS is about *derivation*,
not about construction of step-by-step algorithms that perform some
derivation. By "derivation" I mean that for every current-state and
event there is an algebraic expression that derives next-state. This is
the basic idea behind functional programming. Every derivation is a
"function" that takes one parameter (current state) and by applying the
function, produces the next state. The compiler is responsible for
finding an algorithm to efficiently compute each function.

"Programming" then becomes the job of the compiler. The coder must find
a way to express their computation algebraically, and the compiler does
the rest. Haskell is perhaps the best examplar of this.

Clifford Heath.

John: You asked, I answered. It would be nice to get some feedback.

CH

A lot of engineering delivers non-guaranteed results. Look at almost any domestic electronics for examples.

In mass-market products the engineer doesn't set the goals. The
bean-counters do that, and the engineers have to design to guarantee the
business goals by making cost/MTBF calculations. It's still engineering..

CH

Exactly. Meeting business goals does not always equal guaranteeing the thing works. It just has to sell and not have too many duds be returned.

Consumer products are always guaranteed to work, or your money back.

--

Rick C.

-+-- Get 2,000 miles of free Supercharging
-+-- Tesla referral code - https://ts.la/richard11209
 

Welcome to EDABoard.com

Sponsor

Back
Top