Top front four
ā¦and now you made me realize how long itās been since they won the Stanley Cup.
The funniest part of all of this is that every time I get an email alert on this, it comes in with the from the title, so I think itās going to be someone agreeing with me. But no.
I was specifically talking about @JasonMcD, because Iāve seen some of the stuff heās been able to do with widgets. Obviously YMMV.
But I will argue that every time they re-invent the visual coding wheel, you are relearning a new language anyways. Itās really just a different syntax.
Back to the tools, tools like visual studio do most of what these mousey tools do, and thatās give you a list of possible things you can pick from. But doing it in text is just so much more compact and conducive to copy paste, and things like inserting the ability to use AI to generate the base code (framework) that you need to do something, then be able to easily see and modify what it made⦠These are all ānewā things, that I love. So, I donāt always hate ānewā. I just hate ātediousā.
On the topic of editors, VS code in the browser with intellisense to all Epi objects would be awesome!
But firstā¦can we at least have the ability to pop out/full screen the code editor window? Geesh.
And source code control, diffs, patches, etc.
I built my first configurator in Epicor 12 years ago in classic (obviously). I have now learned how to build them in Kinetic, which was a bit of a learning curve due to App Studio. I am NOT a programmer or coder. Just another geek who thought the configurator was super kewl and so I learned how to program it.
I am currently building 2 configurators in CPQ. And after a relatively short period to learn and get used to Snap, I have to say that I prefer it now over the embedded configurator. It wasnāt that hard to learn the Snap functionality. But as @timshuwy mentioned, I would have to agree that it gives the non-coders a way to see the functionality of whats possible over having to know what syntax to learn. That functionality is just right there in plain sight. And after a bit of playing, anyone can make it do what they want.
As for re-learning the Snap after being able to just write the code, its not that bad. Sure, it took me some time to figure out what a line of code used to do in C# and translate that into what Snap block to grab for similar functionality. But now that transition is well on the way, I have to admit that programming with Snap is very comparable in speed and functionality to C#. I relate it to just having to learn the jargon of the new interface. Like an accent. It sounds/looks a bit funny, but once you get past that, its actually quite similar.
Also, I love the idea of 1 interface for the entire program. So I would have to vote for Snap as the way to go!!
I didnāt mean to start world war 3 with my reply haha apologies to @timshuwy for blowing up his very nice idea, we are a crew of passionate individuals that is for sure.
With the caveat that they wonāt take away the power of BPM as it stands today Iād be fine if this was implemented to supplement or replace the existing widgets.
My impression is this new visual programming would be well-received if:
-
Itās actually better than the existing - easier to read and easier to write, including when things get more complex.
-
Code blocks and expressions are not removed - so devs can still access the wizardry
-
Itās super super super well-tested. This is the part we maybe havenāt seen enough of on the new features released lately. Obviously full-coverage in a complex system is a pipe dream, but at least test all the available controls to make sure they work correctly under normal conditionsā¦
For most functionality I canāt disagree, and maybe my lack of familiarity with Snap is whatās driving this. It seems like complex pricing calculations, calling external BO / Methods, LINQ queries, and JSON-ifying Configurator Input data would be quite difficult and time consuming.
Surely there are enough kinetic bugs and parity issues to go around without introducing yet another new Thing?
Math, context navigation, and data structures are standard prerequisites for CS study. Theyāre an acquirable skill, not an impediment. JSON-ifying in C# looks like: JsonConvert.SerializeObject()
. Languages like C# are for getting work done, so wheels that donāt need reinventing are built in.
Common tediums like serializing JSON are much more work in Snap, because Snap is for education, and serializing JSON from scratch is educational.
My argument isnāt that āreal codeā is better than Snap. Itās that Snap is real code, and users who donāt know that are being told itās not.
What I would rather see is a code-only option for bpms (same like we have in function designer). So much easier to deal with.
Actually what I would love even more than that is just put the bpm options into function maintenance. So when I am writing a function, let me decide whether to hook it up to a method (like a method directive) or a trigger (like a data directive) or leave it standalone (like an existing function). Automation studio has this concept and it makes so much sense. It would align the toolsets, and make it easier to manage the code having it all in one place instead of three different screens.
The kinetic bpm designer is horrifyingly unusable so I really hope that āpower toolsā thing is going to include the classic version if something like my idea above is not implemented.
I havenāt seen how any SNAP looks/works much less CPQās version as we havenāt looked into it (yet?) so I could be wrong but here goes. Just to play devilās advocate here; Doesnāt mean that if they implemented SNAP they couldnāt make a serializing tool/widget, plus other tools not in base SNAP.
And the Broad Street Bullies!
Yessirā¦long-suffering Flyer fan, hoping to see one more Cup win before I go to the Big Montreal Forum in the Sky
You and me both!
My wifeās father grew up in Toronto. HUGE Leafs fan. They moved to London, Ontario where my wife (and her older brother) were born. They are both HUGE Wings fans. Then they moved back to Toronto where her little brother was born. HUGE Leafs fan.
Being from Boston, I donāt talk about hockey with them.
BOS/TORā¦yeah, those games tend to be fun to watch. Longtime NHL Center Ice subscriber. My 3 fav teams are the Flyers, the Leafs and whoever is playing the Rangers.
Harvard uses Scratch in theirs. But as you said, it is the beginning of getting to actual code.