'standard' NDA

[Rick C]

On Saturday, October 5, 2019 at 11:10:48 AM UTC-4, tabb...@gmail.com wrote:

On Saturday, 5 October 2019 07:40:21 UTC+1, Rick C wrote:
On Saturday, October 5, 2019 at 2:01:38 AM UTC-4, tabby wrote:
On Saturday, 5 October 2019 02:13:21 UTC+1, Rick C wrote:
On Friday, October 4, 2019 at 8:20:11 PM UTC-4, tabby wrote:
On Friday, 4 October 2019 20:36:11 UTC+1, Rick C wrote:
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, tabby wrote:
On Thursday, 3 October 2019 20:21:53 UTC+1, John Larkin wrote:

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.

Heh. I'm curious where you imagine you're going to find a political party in Britain that knows what it's doing, and is doing something constructive.

Screw Britain. We have our own problems here. Beside, in 20 years I'm told you will be the single biggest polluter on the planet in no small part because you are incapable of using EVs. We will have to nuke the UK to save the rest of the planet.

So you're not able to recommend any politician in Britain that's acting construstively or even knows what they're doing. That was predictable.

Why should I pay any more attention to British politics than the Brits?

I guess that's one way to confirm what I said.
We're done really.

Actually it was my way of pointing out the absurdity of your question.

Yes, I agree, we are done.

--

Rick C.

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

 

[Rick C]

On Saturday, October 5, 2019 at 3:11:02 AM UTC-4, Tom Gardner wrote:

On 04/10/19 23:56, Rick C wrote:
On Friday, October 4, 2019 at 6:39:02 PM UTC-4, Tom Gardner wrote:
On 04/10/19 21:39, John Larkin wrote:
On Fri, 4 Oct 2019 17:03:35 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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".

The indentation thing is really bizarre. What's wrong with END IF and
NEXT? I suppose I could add my own as comments.

I suspect, without knowledge, that it is derived from the same mentality
that thinks strongly typed languages require too much boring typing and
stop people from changing their code quickly.

I work in VHDL, a strongly typed language and Forth, a virtually not typed
language. Both work well if you use them as intended.

I think for hardware a strongly typed language makes for predictable results
since you in essence have to say exactly what you want rather than being more
vague and letting the tool figure it out. I recall in my youth people would
write C code and once the error messages were gone would ignore the warnings.
The warnings were there for a reason, mostly people just didn't know what
those reasons were because they had not been taught or given it any thought.

Old observation: "cc is half a compiler; the other half is lint"


On the other hand, I find the wild west of Forth to be very freeing
especially when I want to program a custom CPU on an FPGA. I don't need
strong typing because I know exactly what the tools will do with my code, so,
no surprises like you can get with adding std_logic_vector without a strongly
typed package... or in Verilog.

That can work with /your/ code. It becomes more problematic
as you incorporate complex libraries from other companies
(or worse, other projects in the same company!). That
probably does not occur much in your use cases.

"Complex libraries"??? So you create a problem by including a mythical library which by definition has a problem.

What is the intrinsic nature of a complex library that makes it hard to use without strong typing?

I would expect an adequate solution to the complex library problem to be documentation. Without that I don't see how the tools can do much for you anyway.

That may have a little validity for beginners and small amounts of code,
but otherwise strong typing is a strength rather than a weakness.

One of the tenets of Forth is that the design breaks everything down to very
small units which are easy to see and easy to code. By virtue of their size,
they don't really need tools to find mistakes. Each module gets tested and
mistakes are found much more easily.

I've seen far too many people believe their software works because
the unit test light is green. No thought is given to whether the
tests work, whether they test all the necessary functionality,
whether there are common-mode misunderstanding in the code and
tests, whether the spec has been understood, whether the spec is right.

Sure, and no tools will help bad specifications or verification tests.

I recall working on a DSP design that was being a bit flaky in some regard.
A software guy came over and started to focus on a library routine they had
which performed a 16 bit read. It was essentially one line of code with a
very little bit of error checking surrounding it. The guy spend some 10
minutes staring at that code and I kept trying to explain it to him, but he
wouldn't listen. Being C code, it had to use a type cast pointer to access
memory so exactly the right strobes were generated in the hardware.

If you need strongly typed languages to prevent people like him from making
mistakes, I think the problem is you have the wrong guy programming.

C is a horribly complex language where /knowledgeable/ people
argue about what /ought/ to be the semantics of the code. C++
is worse.

To a large extent that stems from C wanting to be both a
close to the silicon and a general purpose high level
language. Either would be good, both simultaneously doesn't
work.

Forth is much simpler in that respect, which is a benefit.

Not sure what that means, "Forth is much simpler"???

A good language enables an IDE (or equivalent tool) to do rapid and
accurate code completion and code refactoring.

Eh? Are you making this complicated? Refactoring is great, but what does
the IDE have to do with it? Maybe this is something I'm just not up on? I
do know in Forth a lot of the tools are called, "the programmer".

The IDE makes it practical to, with a /large/ chunk of code,
say "change this method's name and change the name in all
places where this method is called, checking there are no
naming conflicts anywhere in the code". Ditto with a class.
The main place that can fail is where reflection is used,
but that ought to be used very sparingly.

Maybe I'm not following. Changing a name should be a trivial thing to do using an editor. Search for all existing uses of the new name first. If found, that's not a good choice. If not found, then change it. Where's the complexity?

Ditto with "extract this block of code and turn it into
a method". That one is simple with a text editor; the
others aren't.

That is mindbogglingly simple in Forth. I don't have an editor macro for it, but it is maybe 20 seconds worth of typing and most of that is the documentation for each word.

BTW "large" means 10 of thousands of lines written by
people/projects that you don't know exist.

That excludes anything I would work on. I've never worked on a project I didn't know existed.

BTW, you can't do such refactoring /accurately/ with C/C++.


Fiddling with the language is problematic for IDEs, in the sense they will
ignore your additions.

???

Badly expressed.

Standard languages come with well developed toolsets for
browsing and inspecting and changing programs.

With a Domain Specific Language, you have to write the
tools yourself.

Really? They change that significantly? I thought editors were fairly universal. While many Forth include the IDE few have any special features in the editor other than perhaps ColorForth which uses color as more than just syntax highlighting. Changing the color of code changes when it is compiled/executed. Comments not at all, word names create a dictionary entry, immediate code is compiled/executed when the code is compiled or code is compiled into a word definition. I've not used ColorForth so I can't explain all the details, but it was used to create a CAD system that was used to design a 144 CPU stack processor.

--

Rick C.

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

 

[Rick C]

On Saturday, October 5, 2019 at 12:43:20 PM UTC-4, jla...@highlandsniptechnology.com wrote:

On Sat, 5 Oct 2019 23:42:10 +1000, Chris Jones
lugnut808@spam.yahoo.com> wrote:

On 03/10/2019 00:38, Michael Kellett wrote:
On 02/10/2019 01:55, George Herold 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.

I've seen NDAs from large organisations that are anything from fair and
reasonable to completely daft.
Most seem to include conditions that are broken almost immediately or
are unenforceable.
I've never heard of successful action under an NDA except when backed up
by huge amounts of cash for litigation.
Things to watch out for:

expiry - should be a time limit and a "when it gets in the public domain"
mutual - it should cover both parties (unless v. good reason not to)
reason - certainly under UK law it seems necessary to set out a reason
for it's existence.

also watch out for the ones that require you to "indemnify" your client
in case they get sued later on.

Some people who do potentially dangerous medical products, that we
make little subassemblies for, want US to indemnify THEM.

I always try to turn that around. There is clearly no point in my company indemnifying anyone, but a multibillion dollar company, lol!

The one exception was the requirement to indemnify them if someone makes a claim that my device infringes patents. Not very likely, but hard to argue they should in indemnify me for that.

--

Rick C.

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

 

[Jasen Betts]

On 2019-10-05, Clifford Heath <no.spam@please.net> wrote:

On 5/10/19 1:32 am, jlarkin@highlandsniptechnology.com wrote:
On Fri, 4 Oct 2019 17:42:35 +1000, Clifford Heath <no.spam@please.net
wrote:

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.

That's why modern languages are moving away from the need for such things.

Computer Science doesn't seem to have much interest in computers.

Any computer that is Turing complete can simulate any other computer,
and can compute any computable function. If it wasn't for CS, we
wouldn't even know that. CS folk work in the area of the theoretically
possible (like pure math) not the realisable. That's important, but it
doesn't try to solve business problems.

Computational complexity is another CS invention and helps to solve
business problems in time for the result to be useful.

--
When I tried casting out nines I made a hash of it.

 

[Michael Terrell]

On Wednesday, October 2, 2019 at 11:15:16 AM UTC-4, Phil Hobbs wrote:

It stays in force until the expiry date, if any. I don't sign NDAs that
make my work product their confidential info, and especially not ones
that would make my existing knowledge theirs. Of course I wouldn't sell
the exact same design to somebody else, but they're benefiting from
knowledge gained on previous projects, and I need to be able to keep
doing that.

Cheers

Phil Hobbs

A defense plant in Cincinnati, Ohio wanted the production and test personnel to sign a NDA back in the '70s that claimed ownership of any idea or design for a full ten years from the date that your employment ended. We just tossed them into the trash.

Some of us joked about building flying saucers in our home shops, so the joke at work was, 'Let them try to catch us, once they are flyable'.

 

[Joseph Gwinn]

On Oct 5, 2019, Michael Terrell wrote
(in article<aa2c59a0-aef0-40e3-9841-f90c5aa1c09c@googlegroups.com&gt:

On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown wrote:

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

So, no one else in the world would have ever thought of using AC at any time?

The problem was that nobody knew how to build a motor that worked on AC.
Tesla figured out polyphase power and motors. People didn´t believe him at
first.<https://en.wikipedia.org/wiki/Nikola_Tesla>

Joe Gwinn

 

[Michael Terrell]

On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown wrote:

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

So, no one else in the world would have ever thought of using AC at any time?

 

[Michael Terrell]

On Friday, October 4, 2019 at 6:22:41 AM UTC-4, tabb...@gmail.com wrote:

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

Early elevators were DC powered. I was in Fairbanks, Alaska in the early '70s. They were tearing down an old hotel with one. The huge motor was in the basement. Rather than remove it, it was covered in cement. It was over 12 feet in diameter and about 20 feet long. An AC motor would have had more starting torque, without being so large. An Army buddy of mine came from a family in Chicago that owned a large gem business. They had AC brought in several miles into an old part of town that was still DC powered, because no one still built DC systems when they wanted to add an elevator to their building.

Also, long distance power distribution systems are often built, using HV DC..

 

[Tom Gardner]

On 05/10/19 20:19, jlarkin@highlandsniptechnology.com wrote:

On Fri, 4 Oct 2019 23:38:57 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

On 04/10/19 21:39, John Larkin wrote:
On Fri, 4 Oct 2019 17:03:35 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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".

The indentation thing is really bizarre. What's wrong with END IF and
NEXT? I suppose I could add my own as comments.

I suspect, without knowledge, that it is derived from the
same mentality that thinks strongly typed languages require
too much boring typing and stop people from changing their
code quickly.


I understand that a named Python variable is a pointer to anything,
and can be reaimed at anything. So it's about the weakest typed
language imaginable.

I've only dabbled with Python, but I expect the variable is
untyped but the data is strongly typed. Hence a variable
can "contain" anything, but there's no way you could cast
aCamel to aCar.

That may have a little validity for beginners and small
amounts of code, but otherwise strong typing is a strength
rather than a weakness.

A good language enables an IDE (or equivalent tool) to do
rapid and accurate code completion and code refactoring.

It's usually an interpreter too, no?

Not an interpreter; execution is an improper thought in
this context.

Yes, it fully parses and tokenises (and I don't know what
else!) the source code.

That cannot work reliably where macros are concerned,
nor reflection, nor when interning external serialised
classes or the equivalent.

 

[Tom Gardner]

On 05/10/19 19:55, Rick C wrote:

On Saturday, October 5, 2019 at 3:11:02 AM UTC-4, Tom Gardner wrote:
On 04/10/19 23:56, Rick C wrote:
On Friday, October 4, 2019 at 6:39:02 PM UTC-4, Tom Gardner wrote:
On 04/10/19 21:39, John Larkin wrote:
On Fri, 4 Oct 2019 17:03:35 +0100, Tom Gardner
spamjunk@blueyonder.co.uk> wrote:

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".

The indentation thing is really bizarre. What's wrong with END IF
and NEXT? I suppose I could add my own as comments.

I suspect, without knowledge, that it is derived from the same
mentality that thinks strongly typed languages require too much boring
typing and stop people from changing their code quickly.

I work in VHDL, a strongly typed language and Forth, a virtually not
typed language. Both work well if you use them as intended.

I think for hardware a strongly typed language makes for predictable
results since you in essence have to say exactly what you want rather
than being more vague and letting the tool figure it out. I recall in my
youth people would write C code and once the error messages were gone
would ignore the warnings. The warnings were there for a reason, mostly
people just didn't know what those reasons were because they had not been
taught or given it any thought.

Old observation: "cc is half a compiler; the other half is lint"


On the other hand, I find the wild west of Forth to be very freeing
especially when I want to program a custom CPU on an FPGA. I don't need
strong typing because I know exactly what the tools will do with my code,
so, no surprises like you can get with adding std_logic_vector without a
strongly typed package... or in Verilog.

That can work with /your/ code. It becomes more problematic as you
incorporate complex libraries from other companies (or worse, other
projects in the same company!). That probably does not occur much in your
use cases.

"Complex libraries"??? So you create a problem by including a mythical
library which by definition has a problem.

They are not mythical; including them happens in /every/
non-trivial application I've been involved with.

Examples: the interface to an ETSI Parlay "bus", the widgets
in a GUI interface, image manipulation, high-availability
distributed in-memory caches, various abstractions of ACID
databases.

Those examples are unlikely to be seen in a standalone
embedded application, and that may be the source of your
myopia.

What is the intrinsic nature of a complex library that makes it hard to use
without strong typing?

I would expect an adequate solution to the complex library problem to be
documentation. Without that I don't see how the tools can do much for you
anyway.

The documentation is necessary, but when an application
contains many large complex subsystems developed by many
different companies, brainpower isn't sufficient.

That may have a little validity for beginners and small amounts of
code, but otherwise strong typing is a strength rather than a
weakness.

One of the tenets of Forth is that the design breaks everything down to
very small units which are easy to see and easy to code. By virtue of
their size, they don't really need tools to find mistakes. Each module
gets tested and mistakes are found much more easily.

I've seen far too many people believe their software works because the unit
test light is green. No thought is given to whether the tests work, whether
they test all the necessary functionality, whether there are common-mode
misunderstanding in the code and tests, whether the spec has been
understood, whether the spec is right.

Sure, and no tools will help bad specifications or verification tests.


I recall working on a DSP design that was being a bit flaky in some
regard. A software guy came over and started to focus on a library
routine they had which performed a 16 bit read. It was essentially one
line of code with a very little bit of error checking surrounding it.
The guy spend some 10 minutes staring at that code and I kept trying to
explain it to him, but he wouldn't listen. Being C code, it had to use a
type cast pointer to access memory so exactly the right strobes were
generated in the hardware.

If you need strongly typed languages to prevent people like him from
making mistakes, I think the problem is you have the wrong guy
programming.

C is a horribly complex language where /knowledgeable/ people argue about
what /ought/ to be the semantics of the code. C++ is worse.

To a large extent that stems from C wanting to be both a close to the
silicon and a general purpose high level language. Either would be good,
both simultaneously doesn't work.

Forth is much simpler in that respect, which is a benefit.

Not sure what that means, "Forth is much simpler"???

Forth is simple and orthogonal, without lots of strange history
that enables *experienced* people to discuss what they think *ought*
to happen. Yes, C, I'm looking at you.

A good language enables an IDE (or equivalent tool) to do rapid and
accurate code completion and code refactoring.

Eh? Are you making this complicated? Refactoring is great, but what
does the IDE have to do with it? Maybe this is something I'm just not up
on? I do know in Forth a lot of the tools are called, "the programmer".

The IDE makes it practical to, with a /large/ chunk of code, say "change
this method's name and change the name in all places where this method is
called, checking there are no naming conflicts anywhere in the code". Ditto
with a class. The main place that can fail is where reflection is used, but
that ought to be used very sparingly.

Maybe I'm not following. Changing a name should be a trivial thing to do
using an editor. Search for all existing uses of the new name first. If
found, that's not a good choice. If not found, then change it. Where's the
complexity?

Namespaces/classes preclude that simplistic technique.

I need to be able to rename a Person.fire() method to
Person.dismiss(), and change all invocations of that
method to the new name. Invocations of Missile.fire()
must not be changed.

Ditto with "extract this block of code and turn it into a method". That one
is simple with a text editor; the others aren't.

That is mindbogglingly simple in Forth. I don't have an editor macro for it,
but it is maybe 20 seconds worth of typing and most of that is the
documentation for each word.


BTW "large" means 10 of thousands of lines written by people/projects that
you don't know exist.

That excludes anything I would work on. I've never worked on a project I
didn't know existed.

All the libraries I've used have been written by
people/projects I didn't know existed. Why should I;
all I care about is the library!

BTW, you can't do such refactoring /accurately/ with C/C++.


Fiddling with the language is problematic for IDEs, in the sense they
will ignore your additions.

???

Badly expressed.

Standard languages come with well developed toolsets for browsing and
inspecting and changing programs.

With a Domain Specific Language, you have to write the tools yourself.

Really? They change that significantly? I thought editors were fairly
universal. While many Forth include the IDE few have any special features in
the editor other than perhaps ColorForth which uses color as more than just
syntax highlighting. Changing the color of code changes when it is
compiled/executed. Comments not at all, word names create a dictionary
entry, immediate code is compiled/executed when the code is compiled or code
is compiled into a word definition. I've not used ColorForth so I can't
explain all the details, but it was used to create a CAD system that was used
to design a 144 CPU stack processor.

Simple text editors are universal. Modern toolsets do far more
than that. Welcome to the late 80s / early 90s.

 

[Clifford Heath]

On 5/10/19 5:18 pm, Tom Gardner wrote:

On 05/10/19 07:14, Clifford Heath wrote:
On 5/10/19 1:32 am, jlarkin@highlandsniptechnology.com wrote:
Python looks OK. I should get into that one day.
If you don't like white-space as syntax, look at Ruby. It's similar,
but has a more conventional (and in fact quite beautiful) syntax.
You'll find fewer scientists use it however, and more web wannabe's.

When I glanced at that a long time ago, my it looked like
someone was trying to replicate Smalltalk in Java. But it
was only single-threaded.

It always had threads (with a GIL), but its thread support was weaker
than it is now. There are fundamental conflicts between support for
closures, threads, and generational GC that have made it very hard to
get rid of the GIL. However if you use the JRuby runtime, it's as
parallel as any JVM language. And it has Fibers as well if you need
something lighter-weight.

But a key benefit of Python is the very varied readily
available libraries that plug and play well together.
It shares that characteristic with Java.

Same for Ruby, but the focus is tipped a little further away from
scientific computing than Python. <https://rubygems.org/stats>.

Clifford Heath.

 

[Rick C]

On Saturday, October 5, 2019 at 7:48:56 PM UTC-4, Tom Gardner wrote:

On 05/10/19 19:55, Rick C wrote:
On Saturday, October 5, 2019 at 3:11:02 AM UTC-4, Tom Gardner wrote:
On 04/10/19 23:56, Rick C wrote:
On Friday, October 4, 2019 at 6:39:02 PM UTC-4, Tom Gardner wrote:

I suspect, without knowledge, that it is derived from the same
mentality that thinks strongly typed languages require too much boring
typing and stop people from changing their code quickly.

I work in VHDL, a strongly typed language and Forth, a virtually not
typed language. Both work well if you use them as intended.

I think for hardware a strongly typed language makes for predictable
results since you in essence have to say exactly what you want rather
than being more vague and letting the tool figure it out. I recall in my
youth people would write C code and once the error messages were gone
would ignore the warnings. The warnings were there for a reason, mostly
people just didn't know what those reasons were because they had not been
taught or given it any thought.

Old observation: "cc is half a compiler; the other half is lint"


On the other hand, I find the wild west of Forth to be very freeing
especially when I want to program a custom CPU on an FPGA. I don't need
strong typing because I know exactly what the tools will do with my code,
so, no surprises like you can get with adding std_logic_vector without a
strongly typed package... or in Verilog.

That can work with /your/ code. It becomes more problematic as you
incorporate complex libraries from other companies (or worse, other
projects in the same company!). That probably does not occur much in your
use cases.

"Complex libraries"??? So you create a problem by including a mythical
library which by definition has a problem.

They are not mythical; including them happens in /every/
non-trivial application I've been involved with.

Examples: the interface to an ETSI Parlay "bus", the widgets
in a GUI interface, image manipulation, high-availability
distributed in-memory caches, various abstractions of ACID
databases.

Those examples are unlikely to be seen in a standalone
embedded application, and that may be the source of your
myopia.

I describe my work and that makes me myoptic? You introduced a obstacle into my description and that is what makes it mythical.

You are free to work with anything and discuss anything you want. Please leave me out of it if you can't do it without being insulting.

What is the intrinsic nature of a complex library that makes it hard to use
without strong typing?

I would expect an adequate solution to the complex library problem to be
documentation. Without that I don't see how the tools can do much for you
anyway.

The documentation is necessary, but when an application
contains many large complex subsystems developed by many
different companies, brainpower isn't sufficient.

That doesn't answer the question. The path to working code is to plan and document. Even if the planning is done while you code, everything has to be documented and checked for consistency. Strong typing has little to do with that. Strong typing finds errors in performing wrong operations on a given data type or treating one data type as another inappropriately. I believe a great example of how limited this type of check is would be the destruction of an Ariane rocket. Code was ported from a previous design but was not fully analyzed to suit the new environment. A data type conversion resulted in an overflow and disaster.

Better analysis and documentation would have prevented this disaster.

That may have a little validity for beginners and small amounts of
code, but otherwise strong typing is a strength rather than a
weakness.

One of the tenets of Forth is that the design breaks everything down to
very small units which are easy to see and easy to code. By virtue of
their size, they don't really need tools to find mistakes. Each module
gets tested and mistakes are found much more easily.

I've seen far too many people believe their software works because the unit
test light is green. No thought is given to whether the tests work, whether
they test all the necessary functionality, whether there are common-mode
misunderstanding in the code and tests, whether the spec has been
understood, whether the spec is right.

Sure, and no tools will help bad specifications or verification tests.


I recall working on a DSP design that was being a bit flaky in some
regard. A software guy came over and started to focus on a library
routine they had which performed a 16 bit read. It was essentially one
line of code with a very little bit of error checking surrounding it.
The guy spend some 10 minutes staring at that code and I kept trying to
explain it to him, but he wouldn't listen. Being C code, it had to use a
type cast pointer to access memory so exactly the right strobes were
generated in the hardware.

If you need strongly typed languages to prevent people like him from
making mistakes, I think the problem is you have the wrong guy
programming.

C is a horribly complex language where /knowledgeable/ people argue about
what /ought/ to be the semantics of the code. C++ is worse.

To a large extent that stems from C wanting to be both a close to the
silicon and a general purpose high level language. Either would be good,
both simultaneously doesn't work.

Forth is much simpler in that respect, which is a benefit.

Not sure what that means, "Forth is much simpler"???

Forth is simple and orthogonal, without lots of strange history
that enables *experienced* people to discuss what they think *ought*
to happen. Yes, C, I'm looking at you.


A good language enables an IDE (or equivalent tool) to do rapid and
accurate code completion and code refactoring.

Eh? Are you making this complicated? Refactoring is great, but what
does the IDE have to do with it? Maybe this is something I'm just not up
on? I do know in Forth a lot of the tools are called, "the programmer".

The IDE makes it practical to, with a /large/ chunk of code, say "change
this method's name and change the name in all places where this method is
called, checking there are no naming conflicts anywhere in the code". Ditto
with a class. The main place that can fail is where reflection is used, but
that ought to be used very sparingly.

Maybe I'm not following. Changing a name should be a trivial thing to do
using an editor. Search for all existing uses of the new name first. If
found, that's not a good choice. If not found, then change it. Where's the
complexity?

Namespaces/classes preclude that simplistic technique.

I need to be able to rename a Person.fire() method to
Person.dismiss(), and change all invocations of that
method to the new name. Invocations of Missile.fire()
must not be changed.

Where is the problem exactly???

Ditto with "extract this block of code and turn it into a method". That one
is simple with a text editor; the others aren't.

That is mindbogglingly simple in Forth. I don't have an editor macro for it,
but it is maybe 20 seconds worth of typing and most of that is the
documentation for each word.


BTW "large" means 10 of thousands of lines written by people/projects that
you don't know exist.

That excludes anything I would work on. I've never worked on a project I
didn't know existed.

All the libraries I've used have been written by
people/projects I didn't know existed. Why should I;
all I care about is the library!

Where is the problem?

BTW, you can't do such refactoring /accurately/ with C/C++.


Fiddling with the language is problematic for IDEs, in the sense they
will ignore your additions.

???

Badly expressed.

Standard languages come with well developed toolsets for browsing and
inspecting and changing programs.

With a Domain Specific Language, you have to write the tools yourself.

Really? They change that significantly? I thought editors were fairly
universal. While many Forth include the IDE few have any special features in
the editor other than perhaps ColorForth which uses color as more than just
syntax highlighting. Changing the color of code changes when it is
compiled/executed. Comments not at all, word names create a dictionary
entry, immediate code is compiled/executed when the code is compiled or code
is compiled into a word definition. I've not used ColorForth so I can't
explain all the details, but it was used to create a CAD system that was used
to design a 144 CPU stack processor.

Simple text editors are universal. Modern toolsets do far more
than that. Welcome to the late 80s / early 90s.

And yet people can be uniquely productive without such toolsets.

--

Rick C.

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

 

On Sat, 05 Oct 2019 18:26:57 -0400, Joseph Gwinn
<joegwinn@comcast.net> wrote:

On Oct 5, 2019, Michael Terrell wrote
(in article<aa2c59a0-aef0-40e3-9841-f90c5aa1c09c@googlegroups.com&gt:

On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown wrote:

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

While 110 Vdc generation, transmission and distribution is extremely
short range, motor-generators are not that bad as someone would like
to believe. Motor generators have been used for AC/DC conversion, AC
frequency changing as well as high/low voltage DC conversion.

If I understood correctly, every 10-20th floor in a skyscraper is a
technical floor for air conditioning etc. A motor generator would have
to be installed in each technical floor converting (say 3 kV) DC to
feed 110 Vdc.

For long distance HVDC transmission of more than 100 km at more than
100 kVdc line voltages were used. With several insulated DC
generators in series, such voltages were possible. some individual
generators used double commutators to generating more than 10 kVdc in
each stage

So, no one else in the world would have ever thought of using AC at any time?

The problem was that nobody knew how to build a motor that worked on AC.
Tesla figured out polyphase power and motors. People didn´t believe him at
first.<https://en.wikipedia.org/wiki/Nikola_Tesla

Why did Tesla use a two phase (90 degree), instead a three phase (120
degree) system in Niagara falls transmission ?

Both two as well as three phases can be used to reliably start an
induction motor.

The two phase system requires 4 wires (or three wires with a fat
neutral), while a three phase needs only needs three wires (no
neutral) and can deliver at least as much power as the 4 wires in a
two phase system ?

 

[Tom Gardner]

On 06/10/19 01:49, Clifford Heath wrote:

On 5/10/19 5:18 pm, Tom Gardner wrote:
On 05/10/19 07:14, Clifford Heath wrote:
On 5/10/19 1:32 am, jlarkin@highlandsniptechnology.com wrote:
Python looks OK. I should get into that one day.
If you don't like white-space as syntax, look at Ruby. It's similar, but has
a more conventional (and in fact quite beautiful) syntax. You'll find fewer
scientists use it however, and more web wannabe's.

When I glanced at that a long time ago, my it looked like
someone was trying to replicate Smalltalk in Java. But it
was only single-threaded.

It always had threads (with a GIL), but its thread support was weaker than it is
now.

Yeahbut... Most desktops and above have multiple cores, but
only allowing a single thread to execute at a time means it
can't take advantage of them. That's boring!

There are fundamental conflicts between support for closures, threads, and
generational GC that have made it very hard to get rid of the GIL.

Possibly in Python, but all that is possible and practical
in Java.

However if
you use the JRuby runtime, it's as parallel as any JVM language. And it has
Fibers as well if you need something lighter-weight.

It shows my ignorance, but I thought Ruby ran on the JVM.
I guess that JRuby is a subtly different language.

Multithreading is something that can be (and is) overused
when a thread is mapped onto an o/s process. Fibres probably
help, but I've found ways of recasting my solutions to avoid
it. Short form: one "worker thread" per core, which take
objects from a queue and "execute" them.

But a key benefit of Python is the very varied readily
available libraries that plug and play well together.
It shares that characteristic with Java.

Same for Ruby, but the focus is tipped a little further away from scientific
computing than Python. <https://rubygems.org/stats>.

Life is too short to become proficient in /all/ interesting
languages

 

[Tom Gardner]

On 06/10/19 05:27, Rick C wrote:

On Saturday, October 5, 2019 at 7:48:56 PM UTC-4, Tom Gardner wrote:
On 05/10/19 19:55, Rick C wrote:
On Saturday, October 5, 2019 at 3:11:02 AM UTC-4, Tom Gardner wrote:
On 04/10/19 23:56, Rick C wrote:
On Friday, October 4, 2019 at 6:39:02 PM UTC-4, Tom Gardner wrote:

I suspect, without knowledge, that it is derived from the same
mentality that thinks strongly typed languages require too much boring
typing and stop people from changing their code quickly.

I work in VHDL, a strongly typed language and Forth, a virtually not
typed language. Both work well if you use them as intended.

I think for hardware a strongly typed language makes for predictable
results since you in essence have to say exactly what you want rather
than being more vague and letting the tool figure it out. I recall in my
youth people would write C code and once the error messages were gone
would ignore the warnings. The warnings were there for a reason, mostly
people just didn't know what those reasons were because they had not been
taught or given it any thought.

Old observation: "cc is half a compiler; the other half is lint"


On the other hand, I find the wild west of Forth to be very freeing
especially when I want to program a custom CPU on an FPGA. I don't need
strong typing because I know exactly what the tools will do with my code,
so, no surprises like you can get with adding std_logic_vector without a
strongly typed package... or in Verilog.

That can work with /your/ code. It becomes more problematic as you
incorporate complex libraries from other companies (or worse, other
projects in the same company!). That probably does not occur much in your
use cases.

"Complex libraries"??? So you create a problem by including a mythical
library which by definition has a problem.

They are not mythical; including them happens in /every/
non-trivial application I've been involved with.

Examples: the interface to an ETSI Parlay "bus", the widgets
in a GUI interface, image manipulation, high-availability
distributed in-memory caches, various abstractions of ACID
databases.

Those examples are unlikely to be seen in a standalone
embedded application, and that may be the source of your
myopia.

I describe my work and that makes me myoptic? You introduced a obstacle into my description and that is what makes it mythical.

Reread what you wrote.

In one application I designed there is no way to avoid,
for example, including the interface to an ETSI Parlay
bus or an high-availability in-memory distributed cache.

Both were made by different companies, one with less than
stellar documentation.



> You are free to work with anything and discuss anything you want. Please leave me out of it if you can't do it without being insulting.

Not always. Frequently in large software systems you
work with what you have got and/or are given.

The same is true with hardware systems.

What is the intrinsic nature of a complex library that makes it hard to use
without strong typing?

I would expect an adequate solution to the complex library problem to be
documentation. Without that I don't see how the tools can do much for you
anyway.

The documentation is necessary, but when an application
contains many large complex subsystems developed by many
different companies, brainpower isn't sufficient.

That doesn't answer the question. The path to working code is to plan and document. Even if the planning is done while you code, everything has to be documented and checked for consistency. Strong typing has little to do with that. Strong typing finds errors in performing wrong operations on a given data type or treating one data type as another inappropriately. I believe a great example of how limited this type of check is would be the destruction of an Ariane rocket. Code was ported from a previous design but was not fully analyzed to suit the new environment. A data type conversion resulted in an overflow and disaster.

Better analysis and documentation would have prevented this disaster.

Strawman argument: validation/verification is a different
topic and nobody has argued that strong typing is sufficient.

That may have a little validity for beginners and small amounts of
code, but otherwise strong typing is a strength rather than a
weakness.

One of the tenets of Forth is that the design breaks everything down to
very small units which are easy to see and easy to code. By virtue of
their size, they don't really need tools to find mistakes. Each module
gets tested and mistakes are found much more easily.

I've seen far too many people believe their software works because the unit
test light is green. No thought is given to whether the tests work, whether
they test all the necessary functionality, whether there are common-mode
misunderstanding in the code and tests, whether the spec has been
understood, whether the spec is right.

Sure, and no tools will help bad specifications or verification tests.


I recall working on a DSP design that was being a bit flaky in some
regard. A software guy came over and started to focus on a library
routine they had which performed a 16 bit read. It was essentially one
line of code with a very little bit of error checking surrounding it.
The guy spend some 10 minutes staring at that code and I kept trying to
explain it to him, but he wouldn't listen. Being C code, it had to use a
type cast pointer to access memory so exactly the right strobes were
generated in the hardware.

If you need strongly typed languages to prevent people like him from
making mistakes, I think the problem is you have the wrong guy
programming.

C is a horribly complex language where /knowledgeable/ people argue about
what /ought/ to be the semantics of the code. C++ is worse.

To a large extent that stems from C wanting to be both a close to the
silicon and a general purpose high level language. Either would be good,
both simultaneously doesn't work.

Forth is much simpler in that respect, which is a benefit.

Not sure what that means, "Forth is much simpler"???

Forth is simple and orthogonal, without lots of strange history
that enables *experienced* people to discuss what they think *ought*
to happen. Yes, C, I'm looking at you.


A good language enables an IDE (or equivalent tool) to do rapid and
accurate code completion and code refactoring.

Eh? Are you making this complicated? Refactoring is great, but what
does the IDE have to do with it? Maybe this is something I'm just not up
on? I do know in Forth a lot of the tools are called, "the programmer".

The IDE makes it practical to, with a /large/ chunk of code, say "change
this method's name and change the name in all places where this method is
called, checking there are no naming conflicts anywhere in the code". Ditto
with a class. The main place that can fail is where reflection is used, but
that ought to be used very sparingly.

Maybe I'm not following. Changing a name should be a trivial thing to do
using an editor. Search for all existing uses of the new name first. If
found, that's not a good choice. If not found, then change it. Where's the
complexity?

Namespaces/classes preclude that simplistic technique.

I need to be able to rename a Person.fire() method to
Person.dismiss(), and change all invocations of that
method to the new name. Invocations of Missile.fire()
must not be changed.

Where is the problem exactly???

A text editor cannot correctly determine whether x.fire()
should or should not be changed to x.dismiss().

Neither can a text editor tell you whether there would
or wouldn't be a naming clash with Widget.dismiss().

Ditto with "extract this block of code and turn it into a method". That one
is simple with a text editor; the others aren't.

That is mindbogglingly simple in Forth. I don't have an editor macro for it,
but it is maybe 20 seconds worth of typing and most of that is the
documentation for each word.


BTW "large" means 10 of thousands of lines written by people/projects that
you don't know exist.

That excludes anything I would work on. I've never worked on a project I
didn't know existed.

All the libraries I've used have been written by
people/projects I didn't know existed. Why should I;
all I care about is the library!

Where is the problem?


BTW, you can't do such refactoring /accurately/ with C/C++.


Fiddling with the language is problematic for IDEs, in the sense they
will ignore your additions.

???

Badly expressed.

Standard languages come with well developed toolsets for browsing and
inspecting and changing programs.

With a Domain Specific Language, you have to write the tools yourself.

Really? They change that significantly? I thought editors were fairly
universal. While many Forth include the IDE few have any special features in
the editor other than perhaps ColorForth which uses color as more than just
syntax highlighting. Changing the color of code changes when it is
compiled/executed. Comments not at all, word names create a dictionary
entry, immediate code is compiled/executed when the code is compiled or code
is compiled into a word definition. I've not used ColorForth so I can't
explain all the details, but it was used to create a CAD system that was used
to design a 144 CPU stack processor.

Simple text editors are universal. Modern toolsets do far more
than that. Welcome to the late 80s / early 90s.

And yet people can be uniquely productive without such toolsets.

People can be uniquely productive with handsaws. In most cases
a powered saw is advantageous.

 

[Clifford Heath]

On 6/10/19 6:23 pm, Tom Gardner wrote:

On 06/10/19 01:49, Clifford Heath wrote:
On 5/10/19 5:18 pm, Tom Gardner wrote:
On 05/10/19 07:14, Clifford Heath wrote:
On 5/10/19 1:32 am, jlarkin@highlandsniptechnology.com wrote:
Python looks OK. I should get into that one day.
If you don't like white-space as syntax, look at Ruby. It's similar,
but has a more conventional (and in fact quite beautiful) syntax.
You'll find fewer scientists use it however, and more web wannabe's.
When I glanced at that a long time ago, my it looked like
someone was trying to replicate Smalltalk in Java. But it
was only single-threaded.

It always had threads (with a GIL), but its thread support was weaker
than it is now.

Yeahbut... Most desktops and above have multiple cores, but
only allowing a single thread to execute at a time means it
can't take advantage of them. That's boring!
There are fundamental conflicts between support for closures, threads,
and generational GC that have made it very hard to get rid of the GIL.

Possibly in Python, but all that is possible and practical
in Java.

.... and in JRuby and Rubinius implementations of Ruby.

However if you use the JRuby runtime, it's as parallel as any JVM
language. And it has Fibers as well if you need something lighter-weight.

It shows my ignorance, but I thought Ruby ran on the JVM.
I guess that JRuby is a subtly different language.

Ruby has multiple implementations that conform to the same test suite.
The suite is not exhaustive, but you have to look pretty hard to find
the substantial number of tiny differences.

Matz' original Ruby is called MRI (still has a GIL), and there's
Rubinius (aka rbx), and JRuby which can both use multiple cores. There
are less widely-used implementations also, and many experiments with
evolutionary paths that Ruby might take (c.f. Crystal, which introduces
gradual typing for method signatures).

The JVM suffers from slower startup, but once running it's faster than
the others.

Clifford Heath.

 

[Tom Gardner]

On 06/10/19 10:04, Clifford Heath wrote:
> The JVM suffers from slower startup, but once running it's faster than the others.

Ah, the wonders of HotSpot

 

Joseph Gwinn <joegwinn@comcast.net> wrote in
news:0001HW.23495031004E0EC770000504A2EF@news.giganews.com:

On Oct 5, 2019, Michael Terrell wrote
(in
article<aa2c59a0-aef0-40e3-9841-f90c5aa1c09c@googlegroups.com&gt:

On Friday, October 4, 2019 at 4:35:15 AM UTC-4, Martin Brown
wrote:

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

So, no one else in the world would have ever thought of using AC
at any time?

The problem was that nobody knew how to build a motor that worked
on AC. Tesla figured out polyphase power and motors. People didn´t
believe him at first.<https://en.wikipedia.org/wiki/Nikola_Tesla

Joe Gwinn

He saw it all in his head before he even began starting to make
laboratory proofs. Very quickly advanced into the real thing as a
result.

I like the idea of being smart enough to perform 'tissue' based
prototyping.

The tissues of my mind...

 

On Friday, October 4, 2019 at 9:19:04 PM UTC-4, George Herold wrote:

On Friday, October 4, 2019 at 3:24:59 PM UTC-4, John Larkin wrote:
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.

Hmm where's Tim Wescott. He sorta showed me that there are times where
the D is paramount... Like the thermometers you stick in your mouth and they
give you the final temp based on the slope.

George H.

The D is mostly useful when you have a slow second-order plant, such as a current-controlled motor. Angular acceleration is roughly proportional to current, so a bit of D can help a lot. In more complicated situations such as thermal control, the phase shift increases without bound with frequency, so adding D makes things worse rather than better.

Cheers

Phil Hobbs

 

[George Herold]

On Sunday, October 6, 2019 at 10:54:10 PM UTC-4, pcdh...@gmail.com wrote:

On Friday, October 4, 2019 at 9:19:04 PM UTC-4, George Herold wrote:
On Friday, October 4, 2019 at 3:24:59 PM UTC-4, John Larkin wrote:
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.

Hmm where's Tim Wescott. He sorta showed me that there are times where
the D is paramount... Like the thermometers you stick in your mouth and they
give you the final temp based on the slope.

George H.

The D is mostly useful when you have a slow second-order plant, such as a current-controlled motor. Angular acceleration is roughly proportional to current, so a bit of D can help a lot.

Thanks, As usual I shake my head yes, but I think I'd have to build
something for it to have real meaning. About a year ago my son was
asking about control loops for his quad copter.. I pleaded ignorance of
motors. He has joined the rocketry club at college and is helping them
build drones... so maybe he can teach me about it. :^)

Tim W. made that video with a motor and blade on a balanced stick...
I should go watch that again.
George H.

In more complicated situations such as thermal control, the phase shift increases without bound with frequency, so adding D makes things worse rather than better.

Cheers

Phil Hobbs