|
honey the codewitch wrote: The trouble is there is just so much to it. You have fills, strokes, gradients, textures, fonts, paths, basic shapes, and all kinds of minutia therein.
Lots of software suffer from the checklist syndrome. The designers' / developers' / maintainers' fear is that some customer will ask: 'But can you do so-and-so? Well, if you can't, then I'll have to look for some other alternative!'
In my very first project after getting my degree, the marketing people came to me with checklists from the great reviewers of our software sector: This is what they are looking for. What can we provide today, and when will you have the rest implemented?
My impression is that commercial software have relaxed a little bit with checklists, but open source developers have become increasingly more determined that noone shall reject FOSS because of lacking features. (The current manual of gcc options come in three volumes, doesn't it?  ). I use some commercial software for my home PC and private projects, and FOSS people trying to pressure me into replacing it with FOSS is regularly arguing: But can your software do this? And that? Answering: But I have never had any use for those functions! is - in these discussions - an invalid argument. Even if I never needed a function: If my software doesn't provide it, it proves my software inferior, and I am silly continuing to use it.
Another field where you see this feature creep at full power is in programming languages. Once, language design was clean and manageable. Today, maybe version 1.0 doesn't include everything that all the other languages have - but by version 7.3 they certainly will! Isn't about every single programming language today 'multi-paradigm'? (Who was that stating 'Any sufficiently high-versioned standard is indistinguishable from a can of worms'? That goes for programming languages as well!)
Often, you see software turned down (typically by reviewers, not potential users) on completely irrelevant grounds. To take my oldest example: For my thesis, 40 years ago, I was doing an analysis of a database project that was abandoned. One of the arguments was customers rejected a DBMS that limited a database to 4 GB size. I asked what is the largest database of the current DBMS. The biggest one was 160 MB (note that this is 40 years ago! ) - 4% of the limit of the new system. (That wasn't a design limitation, only the specific proposed first implementation.) I laughed at it then, but during the following 40 years, I have seen similar things numerous times. Reviewers, and potential customers as well, don't have a clue about their real needs. They unconditionally go for 'More is better'. The number of check marks is a primary evaluation criterion, when you don't have sufficient expertise to consider your own need for each feature. Most customers don't. I suspect that a lot of reviewers don't, either.
So, I don't think SVG is any special at all. That is the way software is today.
(Bonus 100% true story: One of my classmates was for his thesis implementing an animation of a data flow model; you could watch how inserting an instance into a data store lead to data traffic among the involved classes. The work was done on a brand new PERQ graphic workstation. The system library could draw any pixel on the screen -- nothing else. (Rather primitive, the way you prefer it ) This data flow model involved 'processes', drawn as rectangles with rounded corners. PERQ couldn't draw 90° arcs. My friend had to implement that himself - our graphics textbook told us how to. The textbook algorithm used a sine function. PERQ had nothing of the sort, so he had to implement a small trig library. The Numerical Methods textbook provided the method, using floating point values. PERQ didn't provide any floating point, so he had to implement a floating point software package, before implementing the trigonometric functions, before implementing the graphic functions for drawing circular arcs, and then he could draw rectangles with rounded corners.
Personally, I prefer the graphic packages of today, capable of drawing circular arcs as a basic function. Disclaimer: I am not currently working in an embedded environment. (And when I was, graphics was totally irrelevant in our applications.)
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
You're right, a lot of people have no idea what they need, and that SVG isn't special in its bloat. It's just overwhelming to deal with.
But I really want nice pretty vector graphics for my little ARMs and stuff, and now the 32 bit ones have enough ooomph to do it.
I just got sick of interfaces that look like they were crafted in the mid 1990s. LVGL seems to find its way around that, even with raster graphics, but I couldn't make heads or tails of its rendering process.
I wasn't really going to do a whole vector engine, aside from loading and rendering a reasonable SVG subset which I already had finished, but not one with an exposed API you could draw with.
The reason I did is I could not find efficient algorithms for doing anti-aliased draws with alpha-blending. The anti-aliasing would cause pixels to be drawn in the same place twice, which fouls alpha-blending.
With vector graphics you get the mess basically as a series of polygons except all the lines are actually bezier curves. When you go to render, the way it's done, the issue above isn't an issue.
But it's sort of an all or nothing deal because the latter works nothing like the former at all.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
At explaining Higgs fields and gravity in an understandable manner? Just came across this, and it seems as foo-foo as every other explanation I've heard: How the Higgs Field (Actually) Gives Mass to Elementary Particles | Quanta Magazine[^]:
> "...As I mentioned earlier, these standing waves are nothing more nor less than motionless elementary particles, rippling in their respective fields."
The engineer in me says that particles must move in order to create waves/ripples, so they aren't 'motionless' 
|
|
|
|
|
David O'Neil wrote: Anyone care to take a stab ... At explaining Higgs
Shouldn't they then write their own article and get it published? After all the link you provided is attempting to do just that.
Myself I feel it comes down to just as the article says is that the problem is in trying to fit the theory into the preceding theories. But that is the point, the new theory is needed because the preceding ones don't work.
I feel it helps to realize that Einstein spent the last half of his life trying to disprove the increasing evidence as it went along that his theory was not in fact complete. Because of course that evidence did not fit into his theory. So one either learns the new discipline completely or just accepts it as unknowable at the personal level.
|
|
|
|
|
Interesting.
The key point "I think" is the example of the ball and string. The ball floating in space can be moved but exhibits no vibration. In a gravity field the ball is held in place by the string and force must be applied to move it. The ball then swings (vibrates) so it exhibits a repetitive motion within the boundaries of the swing (the vibration) but no motion outside of the vibration. The ball exhibits mass via the frequency of the vibration. Now gravity is basically one direction. The Higgs field acts like it but in all directions. So it causes the vibration of stationary particles and the vibration is related to what we call mass to set the particle in motion (outside the range of their normal stationary vibration) we must overcome the inertia of that mass.
(Now my head hurts).
|
|
|
|
|
Gary Stachelski 2021 wrote: (Now my head hurts).
That makes two of us. But I can understand what you are getting at through the pain!
|
|
|
|
|
|
Thanks?  Now it is just couched in a different set of obscurations.
|
|
|
|
|
My understanding of the ripples / standing waves etc. is this refers to the field whose ripples give rise to a particle moving or not. When he stated earlier "... Higgs field makes the elementary particles vibrate at higher frequencies ..." I assumed he was referring to the field associated w/ the particle which does the actual vibrating not the particle itself. There must be better foo foo articles than this. Have you seen this one How the Higgs Mechanism Give Things Mass - YouTube[^] He's a bit above foo foo.
|
|
|
|
|
Here is my stab with a rusty spoon (i.e. a very bad analogy based on the link you provided)
Particles are like boats on a flat lake, the 2D surface of the lake representing our 3D universe.
Without an anchor (massless objects) they go racing about the lake, as the current directs them.
If they have mass then they have an anchor hanging down into the lake. This will not simply hang down, as the water is not thick enough, but will swing back and forth like a pendulum. This will cause the boat to oscillate and that will cause ripples.
(Just about everything in the analogy is wrong, I'm afraid, but I was trying to emphasize the role the anchor plays and how something can be stationary and still cause ripples.)
|
|
|
|
|
It occurred to me the other day that Chat GPT might be able to convert a C# WinForms form to HTML, or at least it would be interesting to try. ChatGPT 4o[^] seems to be a bit improved over ChatGPT 4. I would not be surprised others have tried the same.
So, I created a simple Windows Form, with some labels, textboxes, a drop-down list, a checkbox and a button. I then uploaded the contents of the Form1.cs, Form1.designer.cs, and Form1.resx files to the chat, and asked it to return the code for an HTML page. I also asked it to return a Blazor razor component page.
It did a pretty good job. Not perfect, but for trying to convert the UI portion of a WinForms application, it could save time from simply manually doing the conversion.
I did not try anything complicated, and I would not expect it to translate the C# code to code for Blazor, but I plan to experiment further.
Since this forum is not for programming questions, I am hesitant to provide files, but you should be able to replicate the process yourself.
For those interested, it might make an interesting thread.
|
|
|
|
|
"AI" writing code makes me paranoid to the point where I'd have to review every line to feel good about it.
Most of the time, that means between prompting and review, I'd blow more time than I would solving it myself.
I don't know if that's true in this case, but certainly the review part is an issue.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
That is not the problem here. I am having it do one page from one form.
Yes, of course, I review and revise. I don't expect AI to produce complete, bullet-proof code. I don't have that much experience writing HTML and the byzantine world of CSS. Compared to WinForms (with a designer) and C# code, HTML/CSS (with no designer) is so backwards and unnecessarily convoluted, it saves me time. I have written HTML/CSS by hand like the cavemen did, but it takes less time to design the page in WinForms, then export it via AI (all within Visual Studio) than hand coding the HTML/CSS.
I've known many web front end coders, and they all think they can write a fairly complex page quicker than a designer, but in real world projects, the WinForms folks have always finished well ahead of the hand coders.
The trick is to realize I just want the WinForms to have the UI components and validation code (events in WinForms, things like onclick or mouseover), and let Copilot in Visual Studio generate the Blazor page file(s). From there, almost all of it is just C#. In short, just have AI do whatever takes me more time by hand. I keep it as simple as possible.
|
|
|
|
|
I'm guessing that a lot of you, here on this site, have read this book.
Star Trek Cats[^]
A lot of you mention cats & a lot of you are 100% geek. 
I haven't read it...yet.
|
|
|
|
|
raddevus wrote: I'm guessing that a lot of you
I am guessing not. Unless the word "lot" has a different meaning than I understand.
There is a vast array of stuff out there for various cultural themes. Very few attempt to acquire all of it even if price itself was not an issue.
After all if ones spends all their time and money on Star Trek then what is left over for Pokemon?
|
|
|
|
|
|
But I see that you don't deny that you've read it.
Busted!! 
|
|
|
|
|
raddevus wrote: you don't deny that you've read it.
Check your logic.
To the best of my knowledge, you've never denied committing murder, armed robbery, and drug dealing. Does that imply that you have committed these crimes? 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Duh...this is how the modern world works. Guilty until proven innocent.
|
|
|
|
|
Even though I've been writing code for a long time, I often find that I don't understand things the way I should.
I've been reading Grokking Data Structures[^] (Manning publishers -- I mention because they do a great job on books)
A few years ago I read, A Common-Sense Guide to Data Structures and Algorithms, Second Edition: Level Up Your Core Programming Skills 2nd Edition[^], so along with the experience I have I had a good foundation.
However, this book goes in depth explaining how Data Structures are built on top of UDT (User defined types) and it is absolutely fascinating. The only problem I have with the book is that the samples are written in Python.
I've used a Bag data structure in ASP.NET (ViewBag) but I never really thought about how it is implemented and this book explains that type of stuff.
I'm 70% thru and it's a really great book.
Have you read it?
|
|
|
|
|
raddevus wrote: Have you read it?
Nope, but totally applaud you for peeking underneath the hood to get your learn on.
Jeremy Falcon
|
|
|
|
|
Have not read it. Even though I guess that it wouldn't have taught me very much new stuff, I might have considering buying it, just to pick up the way things are formulated today. But ...
The Amazon sample pages doesn't give me a single sample. I can flip through from the title page, colophon, the brief table of contents, the foreword, the preface, the acknowledgements, the About this book, About the author, and then, finally, eight text lines from the first chapter, which is essentially 'Welcome to this book' (as if all the preceding blurb is not enough of 'welcome'!). There is nothing to show the style of problem discussions, nothing to show the expected knowledge level.
This book is so new that there are no revealing user reviews. The amount of blurb is so large that I honestly do not think this is any sort of directly-to-the-point-with-a-minimum-of-fuzz book for seasoned professionals. So for now, I will not order a copy.
That being said: For the major part of my university, data models (a.k.a. data structures) was an essential part. We spent quite some time on creating database schemas (this was in the CODASYL-relational transition, so we were into both models), we did a lot of work on entity-relationship models (which I still think of as one of the lost pearls of information technology), and class based data modeling.
In our senior year, the last semester, our entire class was split into a number of subproject teams, each assigned to a different main module of a complete software system. The idea was that we should gain experience in cooperating with other teams. The professor in charge had just been caught by some 'functional design' ideas, demanding that all interactions between modules should be through function calls and their parameters, with no common data whatsoever. No data structure design - each module might have some static structures, if they preferred, but none of it should be revealed to others. Seen in a bird's eye perspective, there were no other data than those passed as parameters.
To say that the project failed miserably is to put it in rosy, romantic terms. None of the teams were able to produce anything useful. One significant part of the explanation was that we all had been taught the importance of well designed data structures. Without it, we were lost. But the professor's ideas were coming in like a tsunami, so maybe five years later, when data structures / models teaching had been completely abandoned, those students would have made a greater success.
I have not seen good data modeling returning to the mainstream yet. I still miss it. I still tend to sketch data structures on paper to make clear to myself how complex information sticks together, but whenever I present it to any programmer younger than myself, they are unable to see the data as entities independent of the operations you do on them, but defined by their relationships. Modern programmers immediately start attaching various methods to them, replacing data relationships with one, two or more specific method calls for changing object attributes, pushing aside the relationships of the data model.
From the table of contents of this book, it does not seem to point to data model design. 'Arrays', 'Queues', 'Stacks' is at a very elementary level; it does not suggest system design by data model design. Furthermore, it points towards coding techniques, not modeling techniques.
So I guess that if some youngster comes to me for advice on data structuring, I will have to dig into my basement to find my old textbooks, published 40-50 years ago. Unless someone can suggest newer textbooks on how to do system design based on a data model. Not system implementation and coding - design.
But I guess that doing proper system designs is not agile enough in today's software development environments. System design is intitiated by first typing 'int main(int argc, char **argv){}' and take it from there as ideas and requirements come to mind.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: Amazon sample pages doesn't give me a single sample
Oh, that's unfortunate. I'm reading the book from my oreilly.com subscription where I can read all of these books so I didn't notice that.
trønderen wrote: I have not seen good data modeling returning to the mainstream yet.
There is a weird movement (probably caused by Universities getting stuck on the Functional Paradigm) where new devs are literally saying that OOP is evil. It's crazy.
Instead of learning from the past and building on it, they burn everything to the ground & then start out with dirt & say, "We've built the newest thing. It's dirt and we can make the best structures from it with a little water. And also, we are so much smarter than those who came before us."
Yeah, I've noticed the move away from any type of planning too.
Anyways, the book isn't actually written on that it just gets to the basics of Data Structures.
If you're interested, but you probably aren't.
The Manning book site is actually much better.
Check out this link and you can click on chapters[^] in table of contents and read actual chapters.
I just thought the book was interesting. I've discovered over the years that I often believe that other devs ("architects") know all of this foundational stuff and then I discover that they don't know it either.
|
|
|
|
|
trønderen wrote: demanding that all interactions between modules should be through function calls and their parameters,
Ah...the good old days of RPC (Remote Procedure Calls). Everything was a RPC - even get/set. What more could one want from an ideal world?
trønderen wrote: So I guess that if some youngster comes to me for advice on data structuring,
I will stick with "Algorithms" by Sedgewick.
|
|
|
|
|
jschell wrote: I will stick with "Algorithms" by Sedgewick.
That may very well be an excellent book, but from the table of contents and the available pages, it doesn't at all look like a data structure design textbook. More like a data structure implementation textbook. (It may be excellent at that.)
My rule of thumb is that a design can be implemented in any programming language. Hence, it can be presented and described without resorting to any specific programming constructs. An architect presenting a floor plan to you doesn't go into the kind of wood panel that will be used. The exterior drawing, showing the windows and doors, doesn't go into the mechanism of the window hinges. Maybe the exterior shows the outer walls as flat surfaces, like concrete walls, but you may take the drawings to a carpenter who will build you a wooden house.
To me it looks like the Sedgewick book is not primarily aimed at teaching you how to draw neither the exterior of the house nor the floor plan. Nor the placement of the technical installations. When a designer has created a room of 10,000 data elements, Sedgewick can teach you alternative ways to manage those 10,000 data elements - but not why those data elements were placed there. And how they relate to another 1000 elements. And which properties are shared by those 10,000 elements and how to handle the sharing. And so on.
The title is honest: The book describes algorithms, not data structures. Well, trees and lists and arrays are data structures at the coding level, but they are not made for designing information interrelationships at the problem domain level.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
