Author Topic: 2017 Make with Ada competition  (Read 26060 times)

0 Members and 2 Guests are viewing this topic.

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9209
  • Country: my
  • reassessing directives...
Re: 2017 Make with Ada competition
« Reply #125 on: May 23, 2017, 01:34:47 pm »
I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.
I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.
are you saying that you will accept the test on yourself if its developed in Ada?
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #126 on: May 23, 2017, 02:40:32 pm »
I rather like the (possibly apocryphal) bridge acceptance test: the architect/engineer had to stand under it as all the supporting scaffolding was being removed.
I have seen something similar recently: a local glider inspector insists that after he has repaired/recertified a glider, he is the first one to fly it.
are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.
« Last Edit: May 23, 2017, 02:44:32 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1843
  • Country: ca
Re: 2017 Make with Ada competition
« Reply #127 on: May 23, 2017, 03:32:06 pm »
are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.

Here's what you said elsewhere in this thread:

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Doesn't look too much dissimilar.
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #128 on: May 23, 2017, 04:00:45 pm »
are you saying that you will accept the test on yourself if its developed in Ada?

Now you are just being silly; stop trolling.

Read (and understand) what I have written elsewhere in this thread and you will find you already know the answer.

Here's what you said elsewhere in this thread:

Please try to imagine what you would do and what choices you would make if your code was responsible for, say, your mother's life.

Doesn't look too much dissimilar.

That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.

But perhaps your contribution should simply be seen in the light of your previous point in https://www.eevblog.com/forum/microcontrollers/2017-make-with-ada-competition/msg1214513/#msg1214513
« Last Edit: May 23, 2017, 04:03:30 pm by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 1843
  • Country: ca
Re: 2017 Make with Ada competition
« Reply #129 on: May 23, 2017, 04:26:17 pm »
That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.

Not by much.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9209
  • Country: my
  • reassessing directives...
Re: 2017 Make with Ada competition
« Reply #130 on: May 23, 2017, 05:36:58 pm »
so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 
The following users thanked this post: Frank

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #131 on: May 23, 2017, 05:40:04 pm »
That is indeed one thing I've said. But not the only one. Look again, and find more substantive points.
Not by much.

I can only echo this statement: https://www.eevblog.com/forum/microcontrollers/2017-make-with-ada-competition/msg1214885/#msg1214885
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline Kalvin

  • Super Contributor
  • ***
  • Posts: 1793
  • Country: fi
  • Embedded SW/HW.
Re: 2017 Make with Ada competition
« Reply #132 on: May 23, 2017, 05:57:30 pm »
so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.
Of course, it would stupid to argument otherwise. However, not all languages are equal. C has much more opportunities to shoot yourself into foot compared to Ada, and C++ provides you with many opportunities to shoot yourself into back.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 18015
  • Country: nl
    • NCT Developments
Re: 2017 Make with Ada competition
« Reply #133 on: May 23, 2017, 06:49:30 pm »
so the conclusion is... you can still shoot your foot with Ada, class dismissed. thank you everybody for your participation in this contest.
Yes, you can most certainly cut yourself with a very dull knife. You just have to push much harder  :palm:
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2304
  • Country: de
    • Frank Buss
Re: 2017 Make with Ada competition
« Reply #134 on: May 24, 2017, 12:46:13 am »
Of course, it would stupid to argument otherwise. However, not all languages are equal. C has much more opportunities to shoot yourself into foot compared to Ada, and C++ provides you with many opportunities to shoot yourself into back.

It's not "shoot yourself in the back" :)

http://www.toodarkpark.org/computers/humor/shoot-self-in-foot.html

C:

You shoot yourself in the foot.
You shoot yourself in the foot and then nobody else can figure out what you did.


C++:

You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."


Ada:

If you are dumb enough to actually use this language, the United States Department of Defense will kidnap you, stand you up in front of a firing squad, and tell the soldiers, "Shoot at his feet."

After correctly packaging your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover that your foot is of the wrong type.

You scour all 156e54 pages of the manuals, looking for references to foot, leg, or toe; then you get hopelessly confused and give up. You sneak in when the boss isn't around and finally write the damn thing in C. You turn in 7,689 pages of source code to the review committee, knowing they'll never look at it, and when the program needs maintenance, you quit.
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 
The following users thanked this post: andyturk, Frank

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #135 on: May 24, 2017, 08:35:38 am »
You scour all 156e54 pages of the manuals, looking for references to foot, leg, or toe; then you get hopelessly confused and give up.

Unfortunately that's also true for C++, where "manuals" are the combination of "this year's language definition" plus "compilerX manual" plus C++/compilerX forums plus "C++ FQA". You are left wondering if it is a compiler bug or your not understanding the interactions between all the C++ "features".

You decide to become a manager, and absolve yourself of responsibility by offshoring development to "highly experienced" development teams working for 1/10 of the salary. You leave that job after 2 years - in time to claim management success but before the "suboptimalities" become evident. Your successor has to deal with the "suboptimalities", and deflects blame onto the person that set up the arrangement.
« Last Edit: May 24, 2017, 08:40:39 am by tggzzz »
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4348
  • Country: ch
Re: 2017 Make with Ada competition
« Reply #136 on: May 24, 2017, 10:04:06 am »
Yup, we are all doomed with C++.
All of us  :palm:

( I am considering to move my core business into the field of ice cream sellers
At least it will be more "cool"  :D )
 

Offline Vtile

  • Frequent Contributor
  • **
  • Posts: 990
  • Country: fi
  • Ingineer
Re: 2017 Make with Ada competition
« Reply #137 on: May 24, 2017, 04:08:02 pm »
It is funny to follow these "my dick is bigger than yours" arguments/fights at which programming language is the best for everything.  :popcorn:

Real Programmers use FORTRAN. Quiche Eaters use PASCAL.
« Last Edit: May 24, 2017, 04:21:57 pm by Vtile »
 
The following users thanked this post: Frank, JPortici

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #138 on: May 24, 2017, 04:16:24 pm »
It is funny to follow these "my dick is bigger than yours" arguments/fights at which programming language is the best for everything.  :popcorn:

It is sad when that happens.

I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 
The following users thanked this post: Vtile

Offline Vtile

  • Frequent Contributor
  • **
  • Posts: 990
  • Country: fi
  • Ingineer
Re: 2017 Make with Ada competition
« Reply #139 on: May 24, 2017, 04:38:29 pm »
... and REAL ENGINEERS use relays.
 

Online Mechatrommer

  • Super Contributor
  • ***
  • Posts: 9209
  • Country: my
  • reassessing directives...
Re: 2017 Make with Ada competition
« Reply #140 on: May 24, 2017, 05:24:33 pm »
I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".
yes for example this...
It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.
if something can select, how cant it be intelligent? if something is intelligent, how cant it exist?
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #141 on: May 24, 2017, 06:32:04 pm »
I learned decades ago that engineers should know several different tools (in this case languages) so that they can choose the most appropriate one for their next task. However, too often people get wedded to the tools they know, and mutate "I could use X to do this" into "you should use X to do this".
yes for example this...
It is supposed to be less prone to making stupid mistakes like buffer overruns. Think about a gun which won't fire when pointed at your foot.

It appears that something is being lost in the (two) translation(s).
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4348
  • Country: ch
Re: 2017 Make with Ada competition
« Reply #142 on: May 24, 2017, 08:12:26 pm »
... and REAL ENGINEERS use relays.

Well, it was hard to convince people in the railway business to adopt transistors instead of relays.

Why? Because of the behavior of the relay when it fails: it does it as an open circuit (1), so the train comes into a complete stop. People will be angry but neither dead nor hurt.

When a transistor fails, it does as a short circuit, so the train come across into the stop like a deranged dog, and it will end into an epic disaster.

You can imagine the effort we had to take at promoting the DigitalInfil (made by DSPs, MPUs, a lot of transistors and ... software) for a train which runs at 270-300 Km/h!

At the beginning it was NoGO! (well, they were afraid, because, as you know, E = m * v^2, it's a lot of kinetic energy that a body like a train + passengers possess by virtue of being in motion)

So, we tried to convince them talking about DSPs in redundant configuration, plus a "voter-unit" (special trusted hardware), and firmware written in C, applying MISRA and a similar certification to the DO178B I quoted for airplanes and helicopters.

We spent four years testing the unit in abnormal conditions, to prove it's safe! Also the voter contains relays, so it's intrinsically safe, but the software must be checked and verified to enforce the safety.

And, for your && their pleasure, at the top, in the application layer, we put a software written in Ada  :D


(1) thanks to the gravity!

when a relay decides it's the time to break itself, its coil is not able to contrast the gravity force which pushes the lower lib of the contact in the direction of the ground while the upper lib is fixed in its position. As result, it's open. An open circuit  :D
« Last Edit: May 24, 2017, 08:34:30 pm by legacy »
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #143 on: May 24, 2017, 08:40:15 pm »
... and REAL ENGINEERS use relays.

Nah. Real engineers use fluidic logic gates. They work with gas at ~2000psi.

I once did a study into replacing fluidic logic with microprocessors, and concluded it would be a bad idea. There are significant advantages to fluidic logic in unmanned environments with flammable gasses.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline ealex

  • Frequent Contributor
  • **
  • Posts: 282
  • Country: ro
Re: 2017 Make with Ada competition
« Reply #144 on: May 26, 2017, 11:02:46 am »
personal experience (sorry for the long post ) :

bug 1:
3'rd party embedded os that used some values stored in memory to decide if it's a cold or warm boot:
if ( 0xDEAD == ram[0] && 0xBEEF == ram[1] ) => warm boot. ( they wanted to be "safe" )
in their case, for some reason " && " was actually " || " -> so the code would think that it was a warm boot when only half of the conditions where met so it skipped over some of it's initialization steps and fail some time after when it tried to run code from peripheral space :)

on some mcu's the RAM, after a cold boot, would tend to have 0xBEEF in it ... one in several thousands ...
a nice and frustrating bug ... i think i simulated 1000000 hours of run-time on all the dev boards we had until we got a production unit that failed in the factory - that board failed 5/10 cold boots and could finally find the problem.

in this case no tool would have been able to catch it ...


bug 2:
CAN frame that contained a size byte and some payload.
some application code got the can frame, extracted the size, done some math on it then memcpy from the frame buffer to an array.
well ... sometimes the CAN frame would have a size of 0 ( not documented behavior ) ... -> memcpy with size -1 :)
the kernel killed the application, but only after if corrupted some shared memory that was mapped in the application space and used as a very fast ipc.
=> the code that handled the ipc(mine) was the one that started complaining that someone corrupted it's data => "it's your bug, not mine"

guess who had to spend a "lovely" evening replaying hour-long CAN traces to reproduce / figure out what CAN frame was generating the issue and then finding out where it's failing ...

in this case :
- basic defensive programming would have fixed it from the start, instead of "i'm a high level C++ linux application programmer, input data is always right so the bug is not in my team's code" ( you know the speech )
- Ada might have helped ... if the client actually gave a damn about tools and dev time lost to digging out stupid errors
- review - only if the reviewers have the proper mind set


bug 3:
a simple buffer - a byte array that stored data until all of the chips on the board where up and running.
in some very rare occasions - like 1 in 10000 cycles one of the chips took way longer than expected and the data rate on the input bus spiked -> the buffer overflowed by 1 byte.
just enough to overwrite some stuff from an 3'rd party eeprom emulation library -> the library happily trashed half of the attached flash memory.
on the next boot you had no more system settings or identification data ... no complete failure but you lost some important functionality

again, caught on field and reproduced after days of repetitive testing - it's a joy to work on systems that are not predictable

- review ... maybe, the buffer was already 2x the worst we could estimate
- testing ... you end up having to simulate the entire solar system if you need to be 100% sure :)
- defensive programming : yes, if your constantly enforce this.
- run-time range checks - certainly yes - the cost of lost time + updating all devices that are already on the field might be greater than a full Ada license + training + round the world 5 stars company payed cruise for the team that found the bug :)

=>
there are no magical solutions.
you can make horrible code with the best tools if you rush it and don't give a damn about the result.
or you can make an almost perfect system with assembler and a piece of string as a debugger, if you work on it your entire life.

also, there's the question of cost : how expensive is this failure ?
if your toyota decides to go full throttle for no apparent reason you get an ugly accident with several victims
if your rush-hour filled to the brim subway decides to go full throttle and "extend the tunnel" ... you'll need more than a mop and a bucket to clear up the mess.
i've been in a subway train that had a software crash - the doors where no longer responding, the mechanic manually opened some of them via the emergency release.
he had to power cycle the train to get it going again.


regarding rail-road relays:
 - the are "gravitational relays" - there is no spring to pull the armature in the off position - the weight of the armature does this, so they work only in a specific orientation
 - the contacts are made from materials that do not weld - graphite and silver for example, so they'll disconnect even if the contact points are white-hot
 
The following users thanked this post: Sal Ammoniac

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #145 on: May 26, 2017, 12:44:15 pm »
personal experience (sorry for the long post ) :

No need to apologise.

With your example #1, I wonder if using a stricter language (i.e. one that shows more bugs during compilation) would have encouraged or discouraged a mentality where people don't make presumptions that are justified by "it works" (a.k.a. I haven't seen it fail, yet).

Example #2: well, yes :(

Example #3: yes indeed. As you indicate, you can't test quality into a product. Also sometimes there are good system reasons for minimising buffer size.

And "cost effectiveness" is indeed a very important consideration. A particular problem is where the cost consequences are paid by someone else (i.e. an economist's "externality"). In that case the perpetrator has little incentive to avoid mistakes. We all know too many examples of that :(
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 219
  • Country: gb
  • Do Not Boil
Re: 2017 Make with Ada competition
« Reply #146 on: May 27, 2017, 09:21:54 am »
Thanks for bringing this conversation back to more interesting material. It is indeed the case that where I live in the real world things go wrong on all sorts of interesting and unpredictable ways. I know plenty of Happy-Flow-Programmers who will give you a system that will work perfectly for 99 times out of a hundred and I know plenty of, frankly arrogant, programmers who think they produce bug free code. Neither of those is that useful and anyone who comes to interview with the attitude of "I'm a great programmer, my code is bug free" might as well have saved themselves the cost of the bus fare.

In the best scenario you have weather-worn programmers who know that it's the nasties that catch you out, and who are humble enough to know that they themselves will make mistakes. Unfortunately those greybeards tend to have seen so many programming fads come and go that they are pretty cynical about trying new stuff, despite the fact that modern languages and tools could undoubtedly help them (We had one guy who would _not_ move from Windows 3.11 until I physically disconnected him from the network as a security risk).  The best way to get these people to try new stuff is one bite at a time...which comes back to my original question about GPL; having to make a significant investment in unproven (to me personally, the only judge that counts) technology with unproven benefits is not going to happen, I'll just stick with my c compiler, thanks. There is no point in you wheeling out PowerPoint, statistics and papers showing me how good the alternatives are....the authors of those documents are not going to be the ones standing at a roadside, in a plane or down a mineshaft trying to figure out why 1+1 seems to become 4.

Defensive languages are just starting to hit the embedded space  properly (e.g. rust). As that community is finding, if you give us a way to reverse slowly and carefully into something new and you will find yourself with a set of powerful evangelists with significant influence over the spending decisions of their organisations....but if you demand 'faith' and upfront investment of anything  other than time then ain't gonna happen.

Dave
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #147 on: May 27, 2017, 10:24:56 am »
Thanks for bringing this conversation back to more interesting material. It is indeed the case that where I live in the real world things go wrong on all sorts of interesting and unpredictable ways. I know plenty of Happy-Flow-Programmers who will give you a system that will work perfectly for 99 times out of a hundred and I know plenty of, frankly arrogant, programmers who think they produce bug free code. Neither of those is that useful and anyone who comes to interview with the attitude of "I'm a great programmer, my code is bug free" might as well have saved themselves the cost of the bus fare.

Yes indeed. Fortunately such cowboys are relatively easy to weed out, provided a competent engineer is doing part of the interviewing.

Quote
In the best scenario you have weather-worn programmers who know that it's the nasties that catch you out, and who are humble enough to know that they themselves will make mistakes. Unfortunately those greybeards tend to have seen so many programming fads come and go that they are pretty cynical about trying new stuff, despite the fact that modern languages and tools could undoubtedly help them

I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then :)

Quote
(We had one guy who would _not_ move from Windows 3.11 until I physically disconnected him from the network as a security risk). The best way to get these people to try new stuff is one bite at a time...which comes back to my original question about GPL; having to make a significant investment in unproven (to me personally, the only judge that counts) technology with unproven benefits is not going to happen, I'll just stick with my c compiler, thanks. There is no point in you wheeling out PowerPoint, statistics and papers showing me how good the alternatives are....the authors of those documents are not going to be the ones standing at a roadside, in a plane or down a mineshaft trying to figure out why 1+1 seems to become 4.

I well remember set of presentations of optical fibre measurements being made in lab conditions. My customer then showed a picture of where he would be making his measurements: in a hole in the ground, optionally with water sloshing around :)

Or, more recently, a company where one of their customers had a tendency to throw chairs around.

Quote
Defensive languages are just starting to hit the embedded space  properly (e.g. rust). As that community is finding, if you give us a way to reverse slowly and carefully into something new and you will find yourself with a set of powerful evangelists with significant influence over the spending decisions of their organisations....but if you demand 'faith' and upfront investment of anything  other than time then ain't gonna happen.

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 

Offline mubes

  • Regular Contributor
  • *
  • Posts: 219
  • Country: gb
  • Do Not Boil
Re: 2017 Make with Ada competition
« Reply #148 on: May 27, 2017, 08:12:48 pm »
I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then :)

<SNIP>

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.

Ah, it seems my beard is of similar vintage...although I only go as far back as things like Transputer and VIPER etc. Way back I designed a whole comms system based around the T414 and the worm-routeing stuff that it could do. That chip was so innovative and the channel based comms infrastructure was _really_ clever to my young eye.  Until a little bit of Google I had no idea that the XMOS xC stuff was based on similar concepts (why I love fora like this!)....I can see I need to pull out a few old logbooks and do a bit of reading.  Rust is really dealing with a different set of problems to the CSP-abstractions; They addressed process isolation and message passing in a very elegant way, wheras Rust seems to be targetted much more at addressing the fallout you get from closely coupled processes interfering with each other....a problem you simply don't have if you follow a CSP (OCCAM/xC or Erlang-style) approach. The work that's being done over at http://blog.japaric.io/fearless-concurrency/ is interesting though...but does seem to have a 'safe-C' rather than fundamental new approach feel to it.

DAVE
 

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 10278
  • Country: gb
    • Having fun doing more, with less
Re: 2017 Make with Ada competition
« Reply #149 on: May 27, 2017, 08:48:22 pm »
I'm definitely in that category, but I have always been on the lookout for genuine improvements. I've occasionally found them and pounced on them: C in '81, OOP in '85 and '86, Java in '96, and recently xC. The latter is a triumphant "reinvention" of 70s advanced technology (CSP), by some of the people that were responsible back then :)

<SNIP>

If you regard Ada and SPARK and similar as "defensive" and "embedded", they have been around for >30 years!

Rust is, in my opinion, not as good for parallel programming on multicore systems as CSP/Occam/xC. If you want hard realtime behaviour, then the XMOS multicore processors will guarantee that too.

Ah, it seems my beard is of similar vintage...although I only go as far back as things like Transputer and VIPER etc. Way back I designed a whole comms system based around the T414 and the worm-routeing stuff that it could do. That chip was so innovative and the channel based comms infrastructure was _really_ clever to my young eye. 

I wouldn't get too uptight about the distinctions between CSP, Occam and Transputers: they were a synergistic whole. If you liked them, you'll feel very much at home with xC and xCore processors.

Quote
Until a little bit of Google I had no idea that the XMOS xC stuff was based on similar concepts (why I love fora like this!)....I can see I need to pull out a few old logbooks and do a bit of reading.  Rust is really dealing with a different set of problems to the CSP-abstractions; They addressed process isolation and message passing in a very elegant way, wheras Rust seems to be targetted much more at addressing the fallout you get from closely coupled processes interfering with each other....a problem you simply don't have if you follow a CSP (OCCAM/xC or Erlang-style) approach.

Always wanted to use Erlang, but never had the opportunity.

Quote
The work that's being done over at http://blog.japaric.io/fearless-concurrency/ is interesting though...but does seem to have a 'safe-C' rather than fundamental new approach feel to it.

I've had a quick skim of that URL, and RTFM doesn't feel all that different: bog-standard processors, cooperative multitasking, priorities, now while (1) {} task loops. Having said that, I would feel more comfortable if there were more many-cored processors out there. Bit of a chicken and egg.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf