Author Topic: B# programming language  (Read 14191 times)

0 Members and 1 Guest are viewing this topic.

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
B# programming language
« on: August 25, 2019, 04:04:26 pm »
Has anyone ever heard of it?

http://bsharplanguage.org/

They have a twitter account: https://twitter.com/BSharpTeam
last tweet from 2016.

Apparently the project started in 2006 (or possibly earlier?): https://www.embedded.com/design/prototyping-and-development/4006620/B--A-programming-language-for-small-footprint-embedded-systems-applications-Part-1

still nothing to be seen. Is it just another vaporware project? ;D
« Last Edit: August 25, 2019, 08:18:47 pm by SiliconWizard »
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: B# programming language
« Reply #1 on: August 26, 2019, 05:48:58 am »
Never heard of it. But it's a interpreter... so....

I never understood these choices. On one hand embedded devs are bitching about how in efficient, bloated etc all but their hand-optimized asm code is (overstated to make a point  ;D). And on the other hand we create levels of overhead that are just not necessary...

On the other hand, hardware is getting bigger, better, faster and cheaper. So why not use a RaspberryPI and boot into Linux to read a temperature sensor...  :-//
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: B# programming language
« Reply #2 on: August 26, 2019, 05:49:58 pm »
So why not use a RaspberryPI and boot into Linux to read a temperature sensor...  :-//
Because you use too much power and can be hacked with all the outdated open source sw.   :)
I saw there are now uC that use tens of nA instead of mA.
 

Offline Ampera

  • Super Contributor
  • ***
  • Posts: 2578
  • Country: us
    • Ampera's Forums
Re: B# programming language
« Reply #3 on: August 27, 2019, 06:44:09 am »
I forget who I am sometimes, but then I remember that it's probably not worth remembering.
EEVBlog IRC Admin - Join us on irc.austnet.org #eevblog
 

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: B# programming language
« Reply #4 on: August 28, 2019, 04:00:19 pm »
Never heard of it. But it's a interpreter... so....

Well, as I got it, it was supposed to run on some kind of VM, like Java. Not strictly an interpreter, although I guess you can call it that...

Some people have actually advocated the use of Java on embedded targets. Whether it makes sense is probably a topic that would make for a very long and heated debate.

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: B# programming language
« Reply #5 on: August 28, 2019, 04:37:42 pm »
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.

I don't think either end of the spectrum is a good place to be. You can't be productive if you have to spell out all the bits in a low level language (ASM) but you can not expect that you can get away with every abstraction (overhead) that works on a normal PC either...

But with hardware becoming bigger and cheaper, the balance can shift more towards the abstract (overhead) end, without paying too much a price - depending on the project of course. Lots of project don't need/have critical timing that would require dropping down to ASM, some do.

Oh and the PI comment was meant as sarcasm...   ;D
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: B# programming language
« Reply #6 on: August 28, 2019, 05:01:16 pm »
Oh and the PI comment was meant as sarcasm...   ;D

I got that. ;D

"Software is getting slower more rapidly than hardware is becoming faster."
https://en.wikipedia.org/wiki/Wirth%27s_law

Still completely holds IMO.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: B# programming language
« Reply #7 on: August 29, 2019, 05:06:08 am »
Yes, but for most that is not the point. Economics and time to market are the point.

For a developer that translates to: the more productive you can be, the better. Productivity lies in tools and language (to some degree).
The main problem is that the vendors do not put much effort in innovating their toolset (compilers, -new- language support etc). That and the conservative nature of the seasoned embedded developer, means that C is still regarded as king (generalizing here of course).
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: B# programming language
« Reply #8 on: August 29, 2019, 07:45:47 am »
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.

You can't judge from single sample. There are great chances that SIM card in you phone is Java VM (ETSI TS 102 241). Also many smart cards happen to be JavaCard type.
« Last Edit: August 29, 2019, 07:47:41 am by ogden »
 

Offline TheHolyHorse

  • Regular Contributor
  • *
  • Posts: 179
  • Country: se
  • You don't need to be confused, just understand it.
Re: B# programming language
« Reply #9 on: August 29, 2019, 09:47:21 pm »
I've once seen a embedded Java product. Required lots of memory and didn't perform well.
Perhaps a good prototyping tool, but not for something serious.

You can't judge from single sample. There are great chances that SIM card in you phone is Java VM (ETSI TS 102 241). Also many smart cards happen to be JavaCard type.

Just because it exists almost everywhere and is running on billions of devices doesn't mean it's the best thing ever like a lot of people want it to be. Just look at android, developing anything on android isn't the best experience you're gonna have. IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

But at the same time I'm not some corporation who prioritizes development speed(ie money) more than the actual outcome.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: B# programming language
« Reply #10 on: August 29, 2019, 10:42:59 pm »
Just because it exists almost everywhere and is running on billions of devices doesn't mean it's the best thing ever like a lot of people want it to be. Just look at android, developing anything on android isn't the best experience you're gonna have. IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

But at the same time I'm not some corporation who prioritizes development speed(ie money) more than the actual outcome.

Hammer and screwdriver both are tools, just different. The same about almost everything including programming languages and operating systems - there are and always will be *different* tools for *different* jobs. Speaking of B# language - to me it looks like one of many (failed) startups that hoped to be bought by big business and make founders rich, yet did not succeed.
 

Offline Tony_G

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: us
  • Checkout my old test gear channel (link in sig)
    • TGSoapbox
Re: B# programming language
« Reply #11 on: August 30, 2019, 03:03:24 am »
While the use of the # is annoying, at least they aren't using it to signal a CLR based language.

That said, I'm not sure whether it's better than a main stream Java implementation. Though the no GC is a good point (can't remember if the JVM for embedded provides this or not).

Post back with your findings if you do use it. I'd be interested in hearing them.

TonyG

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: B# programming language
« Reply #12 on: August 30, 2019, 05:32:25 am »
That said, I'm not sure whether it's better than a main stream Java implementation.

Java needs way more resources than B#: "Minimal Java ME Embedded configuration: 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM"

https://terrencebarr.wordpress.com/2013/04/15/this-is-big-java-on-arm-cortex-m3m4/

Such competing language can be better than Java in other sense as well - by being cheaper. This is for SE, only royalties (not including tools & support) but anyway:

https://blogs.oracle.com/jtc/java-se-embedded-pricing-explained
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: B# programming language
« Reply #13 on: August 30, 2019, 05:56:10 am »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.

As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "Wrong code should not compile".

I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: B# programming language
« Reply #14 on: August 30, 2019, 06:26:44 am »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.

"API language"? What are you talking about?  :-// Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.
 

Offline obiwanjacobi

  • Frequent Contributor
  • **
  • Posts: 988
  • Country: nl
  • What's this yippee-yayoh pin you talk about!?
    • Marctronix Blog
Re: B# programming language
« Reply #15 on: August 30, 2019, 06:57:17 am »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.

"API language"? What are you talking about?  :-// Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.

I meant the metaphor or analogy the API is expressed in. The logic and coherence between the different parts of the API. The better this 'language' (not a programming language!) the easier it is to learn it and use it - once you understand the premise on which it is based...

Better?
Arduino Template Library | Zalt Z80 Computer
Wrong code should not compile!
 

Offline TheHolyHorse

  • Regular Contributor
  • *
  • Posts: 179
  • Country: se
  • You don't need to be confused, just understand it.
Re: B# programming language
« Reply #16 on: August 30, 2019, 09:16:55 am »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.

As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "Wrong code should not compile".

I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.

I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower. And not to forget all the extra stuff that isn't really necessary, but that's another topic for another time.
 

Offline Tony_G

  • Frequent Contributor
  • **
  • Posts: 899
  • Country: us
  • Checkout my old test gear channel (link in sig)
    • TGSoapbox
Re: B# programming language
« Reply #17 on: August 30, 2019, 02:44:48 pm »

Java needs way more resources than B#: "Minimal Java ME Embedded configuration: 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM"

https://terrencebarr.wordpress.com/2013/04/15/this-is-big-java-on-arm-cortex-m3m4/

Such competing language can be better than Java in other sense as well - by being cheaper. This is for SE, only royalties (not including tools & support) but anyway:

https://blogs.oracle.com/jtc/java-se-embedded-pricing-explained

Really good point. I've spent way too much time working with i.MX 6 lately :)

TonyG

Offline SiliconWizardTopic starter

  • Super Contributor
  • ***
  • Posts: 14297
  • Country: fr
Re: B# programming language
« Reply #18 on: August 30, 2019, 02:47:10 pm »
That said, I'm not sure whether it's better than a main stream Java implementation.

Java needs way more resources than B#: "Minimal Java ME Embedded configuration: 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM"

https://terrencebarr.wordpress.com/2013/04/15/this-is-big-java-on-arm-cortex-m3m4/

Such competing language can be better than Java in other sense as well - by being cheaper. This is for SE, only royalties (not including tools & support) but anyway:

https://blogs.oracle.com/jtc/java-se-embedded-pricing-explained

Both valid points. Unfortunately, as I said, they never released anything. Not even a single document AFAIK in over 13 years.
 ;D
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: B# programming language
« Reply #19 on: August 31, 2019, 10:01:22 pm »
I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower.

If something is unnecessary, then what's the point of using it? Typical example - embedded programmers complaining that stm32 HAL libraries are "bloated". Well.. they are - for those who want to compile their "Hello World" example fast and for free. So what? If you want something better then buy it or create yourself.
 

Offline Vtile

  • Super Contributor
  • ***
  • Posts: 1144
  • Country: fi
  • Ingineer
Re: B# programming language
« Reply #20 on: September 10, 2019, 06:41:47 pm »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else.

"API language"? What are you talking about?  :-// Hardware Abstraction Layer shall never be part of programming language. It's just library at best, sometimes not even that. Language shall provide hardware *access*, not abstraction.
API is just part of the system knowledge or process knowledge. Nothing to do with programming or programming language itself.. Same with memory management, it is just pea counting.
 

Offline Vtile

  • Super Contributor
  • ***
  • Posts: 1144
  • Country: fi
  • Ingineer
Re: B# programming language
« Reply #21 on: September 10, 2019, 06:48:32 pm »
IMO I just feel limited by all these abstractions and layers to "simplify" things, but at some point you're just shooting yourself in the foot.

Choosing the right abstracts and "API language" is a true art. When done well, programming peripherals become one-liners that you still understand after 6 months doing something else. These 'unnecessary' layers of abstraction are needed for when project become more complex and elaborate. At a certain point you cannot hold the details of the entire program in you head and you need to hide complexity behind an abstraction. Also when the API is designed well, it's very easy and quick to learn and use it in your program.

As for the language, I think a we can do a lot better than C. I would go for a subset of C++ just because most vendors have some level of support for it. Also meta-programming (C++20) is something to keep an eye on (beyond constexpr). That would allow you to express a lot of static stuff at compile time and control what can and cannot be done at runtime. "Wrong code should not compile".

I have serious doubts if any custom language could ever get the traction and maturity of a well established language, like C++ (breadth of support, tools, community etc). If you want to try something new, I would take look at Rust, which looks promising.

I'm not saying all layers of abstraction are bad, it's the unnecessary layers that are. This is happening more and more these days and is probably the reason why software is getting slower. And not to forget all the extra stuff that isn't really necessary, but that's another topic for another time.
It is how you make the abstraction, if done correctly it simplifies if done poorly is makes things more complex. For my thin (I do mean thin) knowledge and experience with many system with "abstraction" it usually makes things more complex and harder to really understand, like example poorly documented do it all libraries (with usually colliding logic or nomenclature with parent system). Besides when talking general programming languages the interface is always textual functions, calling layers of more or less mystery functions.  Which is tried to compensate with fancy monsters (even more hidden behavior with textual interface) and tabulations.
« Last Edit: September 10, 2019, 06:54:07 pm by Vtile »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: B# programming language
« Reply #22 on: September 11, 2019, 01:25:50 am »

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)


Other than assembly language, only 3 languages pass the test of time:  FORTRAN, COBOL and C.  Everything else is just a passing fad. 

FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power.  We’ll have to watch and see.
 

Offline Dubbie

  • Supporter
  • ****
  • Posts: 1114
  • Country: nz
Re: B# programming language
« Reply #23 on: September 11, 2019, 01:55:01 am »

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)


Other than assembly language, only 3 languages pass the test of time:  FORTRAN, COBOL and C.  Everything else is just a passing fad. 

FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power.  We’ll have to watch and see.

You forgot FORTH  :-DD
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: B# programming language
« Reply #24 on: September 11, 2019, 02:29:50 pm »

It's "interesting" though to see how much programming languages still spark initiatives all over the place (while successes are very few...)


Other than assembly language, only 3 languages pass the test of time:  FORTRAN, COBOL and C.  Everything else is just a passing fad. 

FORTRAN 1957 - still used for scientific computing
COBOL 1959 - still used in banking
C 1972 - A newcomer but it seems to have staying power.  We’ll have to watch and see.

You forgot FORTH  :-DD

It's only been around since 1970 (coincidentally, the year I started using the IBM 1130 and Fortran) but I don't consider it in common use.  More of a curiousity and popular in certain niche applications but definitely not mainstream.  Neither is APL and although Algol is the grandfather of all block structured languages, it too lies on the ash heap of history.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf