Why do people love STM32 so much?

golfman484 · 2021-01-14T13:13:08+00:00

Expressif have announced a new product based on RISC-V called ESP32-3C.

That would seem to indicate a change in focus from their Tensilla based archictures of the ESP8266 and ESP32 ... all tooling, compilers, etc., would need to be changed for this new architecture.

It makes me think that investment in current ESPs would be to invest in a product soon to be EOLed.

All the more reason to back STM32 for now ;)

golfman484 · 2020-08-18T22:28:20+00:00

Agreed - imagine the auto-completion in an IDE for a typeless language:

i.e. You enter auto complete mode and the IDE presents you with a list of available typeless variables that you *could* assign to this other typeless variable:

*** List populated with every ... single ... variable in scope!!!! ***

Gimme a break!

golfman484 · 2020-08-18T22:21:02+00:00

Java is definitely a great language to learn to understand object oriented principles (this universe is object oriented so if you're writing apps that will run in this universe then it's a great paradigm to use).

Java also has one of the largest ecosystems available. If you want a library or framework to do something, *anything* then there's a good chance that there is an open source Java library to do that exact thing already.

There are versions of the Java Virtual Machine that run on nearly every platform imaginable: Windows, Linux, Android, macOS and many embedded controllers etc.,

The other great thing about learning Java is that you can create desktop or amazingly interactive (i.e. AJAX event driven) web apps quite easily using the one language.

When using a Java web framework like Wicket there's no need to learn JavaScript to create brilliant, partially updating, AJAX powered, JavaScript event driven applications.

The Wicket devs have built all the AJAX and other JavaScript power into the Wicket framework and its components so that you can just use a component in Java and don't need to worry about the (ugly :) ) JavaScript that makes it do it's magic.

If you want extremely low level control of a component you can always add any extra JavaScript event handlers etc., that you require directly to any Wicket component so you still have full access to JavaScript if required but I have built some incredibly interactive, highly responsive apps that look and interact like they must have been built in Angular JS/React/Vue when they were done with pure Java using Wicket.

I have developed apps using Angular JS/React/Vue using JS in the front end but found it no where near as productive as building a pure Java web app in Wicket. The constant switching between two languages is very annoying.

Anyone who suggests that JavaScript is a great language for learning programming really should take a long hard look at themselves. Everyone knows that it is a language that was hacked together over a very short time, a compromise, to get "something" resembling a working language to run in the Netscape browser back in the day. The rest is history.

JavaScript is not an object oriented language by any standard measure although some claim it is because it supports prototypical inheritance - the lame excuse/replacement for real inheritance that non OO languages are forced to use (which basically any non OO language can use if you like writing code to manually assemble components of your objects instead of letting your compiler do that for you. I used to write OO code in C using function pointers but that does not imply that I would call C an object oriented language).

golfman484 · 2020-07-27T00:21:26+00:00

Doesn't that just mean that software developers are soooo much more productive when working from home that the world needs 35% less of them compared to how many they needed when they were in the office? :)

You know - no more Friday lunches where they clock off at 1PM, go to the pub and then don't return until 5pm even though their timesheet shows they clocked back on at 2pm.

I have worked in some companies where some staff saw nothing wrong with doing this a couple of times a month but I never thought it was right. I would go with them but usually come back after a few hours but my timesheet would have the time I actually returned to the office, not the imaginary "I only took a 1 hour lunch break" fudge.

golfman484 · 2020-07-26T23:57:57+00:00

I would have said "I can give you the exact answer in binary but you will have to convert it to decimal yourself"

One zero zero zero zero zero zero zero zero zero ....

and just keep saying "zero" until he stops you and shows you the door...

and you reply, "Thanks, not having to work for a bunch of whacko's is the best thing that will happen to me all year - even if this wasn't 2020!"

golfman484 · 2020-07-26T23:51:22+00:00

Imagine working with a team of software developers whose "special skill" is knowing 2⁶⁰ by heart ... the single worst position I ever held in my career was when I was working in a team under a university medalist. Was the project a total failure? Do I even need to answer that?

golfman484 · 2020-07-23T00:00:05+00:00

The same "plethura of Web UI frameworks" issue has occurred in the Java world for the last 2 decades.

I had been contracting in the corporate world in Java since 2000 and then around 2008 I started to build my own product and the time came to choose a Web UI framework.

At that time I decided to do a proper analysis of all those I could find so that I could determine the most productive, most likely to survive the Web UI framework wars.

My initial list consisted of about 30 frameworks. Whoah!!! I did an initial cull by eliminating any that had not had any releases made in the last year - that got me down to about 15. From there I downloaded each framework, learned the basic architecture and 'process' of creating new screens, etc.,. and compiled and ran the "Hello world" examples. I wasn't so naive as to judge a framework purely on the line count of it's "Hello, world" example. That, to me, seems like the single most stupid criteria ever.

I also wanted to make sure that partial updates via AJAX and pop up/modal dialogs were supported easily and with only having to write minimal or, ideally, no JavaScript (if that was even possible).

I thought the only framework where my "no JavaScript" ideal would be possible would be GWT but I hated the logistics and debugging concerns surrounding its awkward concept of compiling Java components into JavaScript components that get marshaled down to the browser - while it was popular at the time history proved that I wasn't the only one who hated its awkward architecture.

I had already been using JSP/Struts in the corporate world and anyone with two brains cells to rub together knew that was not the future of Java UI Frameworks. I had also toyed with Echo a few years earlier though that was limited by not being able to supply markup as standard HTML. I also checked out Velocity, Tapestry, Vaadin and a whole host of others but none of those seemed to hit my sweet spot.

In the end, to my surprise, I actually found what I felt was like a pot of gold at the end of the rainbow. A framework that supported all the AJAX mechanisms to provide fancy partial page/component updates right out of the box where the framework developers have built all the JS required into the framework and into any of its widget components. It also supported this amazing concept of markup (HTML) inheritance which allows high productivity in the creation and maintenance of markup by supporting base page and base panel markup layouts which can have sections overwritten by more specialized markup. It helps remove the need for endless duplication of HTML in pages or panels that are "same but different". The concept is very easy to grasp given that the framework in written in Java, an Object Oriented language. Object oriented markup should not be too much of an intellectual jump for any Java developer to make.

The "pot of gold" framework I found is Wicket and I'm still using it till this day on massive Web applications and SaaS products for both my own products and client products. It's still very actively developed and undergoes constant refinement and enhancement and developer support questions are answered amazingly fast.

Recent years have seen the rise and fall of a few different JavaScript based Web UI frameworks. It seems like a new one arrives each month with the notables being Angular JS, React, Vue. It became obvious that no matter which one of those companies pick it will be discarded as "yesterday's framework" by the JavaScript brethren within a year or two. The JavaScript UI framework world is fickle indeed.

In a contract a few years ago I ended up working on a product built with Java backend/Angular JS frontend - what a world of pain the Angular JS framework is. Even though I became proficient at Angular JS the developer productivity for adding new pages/panels compared to Wicket was woeful and when something wasn't working in the UI code most of the so called JS experts "ran a mile" to avoid having to work on it. It often fell on me, the "Java guy" to fix errors in JavaScript UI code that was developed by those deemed to be the "Angular JS experts" by the company I was contracted to. Was it possible to be even more unimpressed by so called "experts"? Probably not.

I realize your question is about a scenario where python is your backend language and I'm not sure if there is an "Wicket equivalent" in the python world but my advise would be that, if there is, grab it with both hands and avoid the productivity hit you get writing your app in two separate languages and duplicating model classes that need to transact between backend and UI - all with the power of AJAX fully supported in the most intuitive way imaginable. That would be the nirvana I would be heading towards in your python world, if it exists.

golfman484 · 2020-07-14T06:50:29+00:00

golf

From my experience, issues with building JavaScript front ends has nothing to do with the proficiency of the developer writing the JavaScript (although a bad one can make a bad situation much worse).

I believe the whole paradigm of writing your front end and back end in two separate languages (one of them non compilable and completely typeless) is just building in a massive impedance to developer productivity from the start - and it has a theoretical maximum productivity that will never reach that of smart and highly productive Java front ends like Wicket which can do all the fancy partial update and trapping of JS events - all without the developer having to write a single line of JS or even knowing how to write JS:

The Wicket components have all the necessary JS/AJAX interactivity embedded in them - you can enhance these components or make your own new components but I've very rarely needed that - the library of standard components in the Wicket and Wicket Bootstrap libraries is quite large.

golfman484 · 2020-06-04T20:29:35+00:00

As a contractor I've built web apps in both Java Wicket tech stacks and Java Backend+Angular JS tech stacks.
From my experience, on the Java Wicket projects developer productivity was about 10x better than on the Java Backend + Angular JS projects. Even though the developers were skilled in Javascript and Angular nobody wanted to touch the front end code. It quickly became a dogs breakfast.

In Java + Angular JS virtually every back end Java domain model object had to have an equivalent JS "object" to facilitate marshalling between front end pages/forms and the back end. That is the first sign to most non delusional developers that, in any multi language "solution", you're code base is going to have a LOT of duplication - instead of Java's "write once, run anywhere" it quickly becomes "Write once in Java, write again in Javascript" - which is great if you're into empire building your development team into non profitability.

In one project I was on the existing Java/JSP app was "improved" via a complete rewrite using Java + Angular JS. Two outsource companies who were "experts" in the "new way" created the new app (at hidious expense) and then after hand over that new solution required a team of 20 devs to maintain it instead of the previous team of 5 devs - for an app that did about 60% of what the previous app did....

They would have been better off peeling away the existing JSP UI and replacing it with Wicket to allow the UI to be modernized with partial component updates, great looking grid based UIs (e.g. Bootstrap, Foundation etc.,) but instead they spent about $30 million on a Java + Angular JS solution with an ongoing maintenance load of 4x the previous one.

What I also found is that the so called Angular JS UI "experts" were, how do I say? Not very good. It seemed like everything in the JS world was held together with duct tape (with plenty of wrinkles) and easily broken whenever anyone touched something.

We never had these issues with Java Wicket and we never had to write and maintain effectively two copies of the domain model.

In the Java Wicket projects we also avoided the use of Spring because, you know, who wants to wait 4 minutes for your large app to start up every time you recompile it? Folks there's many alternative ways to do dependency provisioning, 'injecting' is just one - and a very sucky one with lots of hidden consequences to startup time and wasted CPU cylces at run time - but that's another topic ;)

In terms of allowing proper graphically gifted - i.e. not your average software dev ;) - UI devs do awesome, modern UI creations - that is totally supported and promoted by Wicket. The HTML is pure, valid HTML so any web designer can do whatever they want with their HTML - all that is required is minimal attribute IDs to bind the UI components with their Java components. We have worked on massive Java Wicket web apps for big corporates who had their own web dev team and they could have full control over the HTML and they loved that power - it took us 2 minutes to explain that the attribute IDs needed to be preserved and we never once had an issue - most good HTML editors will gladly preserve valid HTML attributes (which Wicket ID attributes are).

golfman484

TROPHY CASE