Philosophy Discussion Forums | A Humans-Only Club for Open-Minded Discussion & Debate

[Steve3007]

Yes and no on Subjects and BehaviorSubjects being like classes (I'm familiar with them from RxJS but I don't know whether they're based on identical concepts in other places - probably are - or what the names of those features would be in the language(s) you're familiar with). They can contain classes but really they're a bit more like defined contents of an observable (an observable is something you can subscribe to somewhere else in the program, that subscription watches for changes in that content, etc.).

OK. The terminology is a bit unfamiliar to me. I googled "Angular observables" to get an idea of what they are, but I hadn't heard of them before. My experience started with various dialects of BASIC and machine language and then went on almost exclusively to C and C++ with some C# for putting together quick PC based GUI applications. Most of the work I've done has been Windows/PC based, with some mobile app development (using a now-defunct system for writing cross-platform mobile apps in C++ called Marmalade) and a bit of Linux based stuff.

Also I see you just used a word I understand - pointer - so you're a systems guy eh?

It's really just because I'm primarily a C++ programmer and pointers are central to C++.

[Pattern-chaser]

I didn't get a formal education in programming...

Neither did I. Not initially. But as I learned I realised that I needed more than I had. I started off learning different languages, but that didn't give me what I needed. It was only when I started to learn how to design software that I was finally able to proceed and grow. Learning about design patterns was a worthwhile step on that journey. [Sorry if I'm preaching. This is something I've been passionate about for many years.]

[Pattern-chaser]

My experience started with various dialects of BASIC and machine language and then went on almost exclusively to C and C++ with some C# for putting together quick PC based GUI applications. Most of the work I've done has been Windows/PC based

[...]

It's really just because I'm primarily a C++ programmer and pointers are central to C++.

That about sums me up too, although 97% of my work was in the realm of firmware, so most of my work was developed on PCs, but ran on proprietary kit.

[Steve3007]

...although 97% of my work was in the realm of firmware, so most of my work was developed on PCs, but ran on proprietary kit.

I've probably asked you this before, but when you say that do you mean your work was on embedded micros or on things like FPGAs (Field Programmable Gate Arrays)?

[Pattern-chaser]

...although 97% of my work was in the realm of firmware, so most of my work was developed on PCs, but ran on proprietary kit.

I've probably asked you this before, but when you say that do you mean your work was on embedded micros or on things like FPGAs (Field Programmable Gate Arrays)?

Mostly on embedded microcontrollers. In my world, FPGAs remained in the realm of hardware, a realm very close to where I lived, and with which I had an intimate connection. But I never programmed one, except maybe as a peripheral to the uC I was programming. I occasionally worked on microprocessors too, when they had all the uC peripherals on the PCB, in the Goode Olde Days. My C++ experience was on a PowerPC in a telecomms environment. That was when I first heard of design patterns, and started reading comp.object (is that what it was called?).

[Papus79]

Neither did I. Not initially. But as I learned I realised that I needed more than I had. I started off learning different languages, but that didn't give me what I needed. It was only when I started to learn how to design software that I was finally able to proceed and grow. Learning about design patterns was a worthwhile step on that journey. [Sorry if I'm preaching. This is something I've been passionate about for many years.]

No, all of that makes sense.

On some level I am still trying to suss out whether the languages I'm using would be my preferred and beyond that which languages fit which use cases best.

As far as design patterns are concerned I feel like I'm picking that up well just that having learned in a trial-by-fire way my first order of business is 1) find a way of doing what I want to do that's reliable 2) if the way I learned it was the first and worst I keep cutting away pieces until I know what's doing what and keep the minimum working parts, then 3) as I learn to use something I may see an even more simplified version of the same thing I was doing that gives me everything I need with still less code and still fewer working parts.

In that sense the way I feel like I've been learning best is reverse-engineering what's available in other places. When I was first learning Angular (around 2017-2018) it was too new for there to be any worthwhile books or anything that would stay current so it was a constant rotation through StackOverflow, Medium articles, etc. and whenever I saw something done seven different ways and none of them quite did what I needed I'd keep trying to figure out which pieces were essential, what did what, try to then hone my search terms better for Google, know that I was getting closer to hitting pay-dirt when I could put a few specific terms in and get a bunch of StackOverflows or other forums with other people asking the same questions.

From there I've come up with a lot of things I didn't really see anywhere, like three or four lines of code in different places to handle jwt refresh tokens for securing .Net Core / Angular API's (refresh tokens set an expiration ceiling on access tokens and often get stored in SQL with the user account - once they time out the login expires and the user gets kicked out to log in again). It wasn't that running EntityFramework was that hard, just that .Net Core Identity is very particular and I'd have to say at least at this point (my first response had a bit of this as well) - my least favorite thing is incorporating black boxes into my code, I get rid of them where I can just that .Net Core Identity is one I feel like I need to go with - at least until I feel like upgrading to something like Identity Server 4.

[Pattern-chaser]

Neither did I. Not initially. But as I learned I realised that I needed more than I had. I started off learning different languages, but that didn't give me what I needed. It was only when I started to learn how to design software that I was finally able to proceed and grow. Learning about design patterns was a worthwhile step on that journey. [Sorry if I'm preaching. This is something I've been passionate about for many years.]

No, all of that makes sense.

Oh good! I actually wrote a blog that extends what I've written above. It's not too long, so easy and quick to read. Here it is.

[Pattern-chaser]

I actually wrote a blog that extends what I've written above. It's not too long, so easy and quick to read. Here it is.

I wrote a series of blog posts about design. The series ends with my magnum opus, entitled "Now is the time to say goodbye…". If you decide to read them, I'd be very interested to know if you find them useful, or informative? They're all quite short, so the effort involved shouldn't be too demanding.

P.S. Some posts are about hifi, and a couple are about being autistic. But most are about the design of firmware.

[Pattern-chaser]

In that sense, the way I feel like I've been learning best is reverse-engineering what's available in other places.

Yes, seeing how someone else solved a similar problem to your own is a great way of learning. I did it a lot, especially during my earlier learning. But the modern habit of copying and pasting code from the net worries me. It's not the practice itself, but the inclusion of code in my design whose working(s) I don't understand fully, or even at all. That is a guarantee of disaster. The only uncertainty is when the disaster will occur.

I found a good way to understand imported code is to refactor it to suit your own coding standards, and to fit into your own design. This usually aids understanding. With a little experimentation added, in demanding circumstances, and you are well on the way to understanding. If your imported code has no unit-tests, writing some will also help (a lot) to understand it.

All IMO, of course. You'll have to stop me if I'm rambling. This is a subject that I have been passionately interested in since I left University in 1978, and found that I knew nothing of design. They had taught me nothing at all about it, or how I should go about it, even though my first professional job title was "Design Engineer".

[Pattern-chaser]

I've probably asked you this before, but when you say that do you mean your work was on embedded micros or on things like FPGAs (Field Programmable Gate Arrays)?

I said no before, but that isn't entirely true. Way back when I was a hardware designer, I used PALs when they first appeared. They were FPGAs, but we didn't call them that then. I think 16L8s were the first really good ones, followed by AMD's (?) 22V10. I programmed all of those, forcing them to do all kinds of wonderful things that would've been difficult before they appeared.

But I think you refer to those monstrous Xilinx devices, of the kind that empower my Chord Mojo to do such amazing things to my music? No, I never touched those.

[Steve3007]

But I think you refer to those monstrous Xilinx devices, of the kind that empower my Chord Mojo to do such amazing things to my music? No, I never touched those.

Yes, we program for Xilinx devices using the VHDL language. Well, I don't. Our FPGA guy does. It's all Greek to me.

It's not the practice itself, but the inclusion of code in my design whose working(s) I don't understand fully, or even at all. That is a guarantee of disaster. The only uncertainty is when the disaster will occur.

That's the trouble with designing applications to run as a small cog in a big machine, such as applications to run on Windows or non-real time Linux. You have to make use of vast swathes of code that you don't understand and that isn't guaranteed to be deterministic. You have to download huge sledgehammer libraries to crack small nuts. I'm wrestling with that problem right now, on Linux. I hate Linux.

[Papus79]

I found a good way to understand imported code is to refactor it to suit your own coding standards, and to fit into your own design. This usually aids understanding. With a little experimentation added, in demanding circumstances, and you are well on the way to understanding. If your imported code has no unit-tests, writing some will also help (a lot) to understand it.

I think of extra code or 'received wisdom' that doesn't get checked as a bit of coder's superstition (a bit like baseball players can get into their OCD rituals to amp up their belief in their capacity to hit). At best it's benign but as you said, without testing it you won't know what it does and the bigger loss IMHO is not knowing all the other use cases where you could use a popular function of some kind (some examples in javascript - pipe, map, reduce, ... spreader, etc.). Sometimes if you're on someone else's clock you're kind of stuck with this but I find that anytime I have spare time or a few hours that I don't know what to do with - it's a great time for going back and challenging received wisdom.

All IMO, of course. You'll have to stop me if I'm rambling. This is a subject that I have been passionately interested in since I left University in 1978, and found that I knew nothing of design. They had taught me nothing at all about it, or how I should go about it, even though my first professional job title was "Design Engineer".

I think the way it's going to likely continue to be for me - I've had two very different kinds of projects now, quoting app and finance app. For the finance app it was really useful for me to figure out that I was really dealing with two or three different systems (contractual cycles vs. accounting for example) and being able to treat them as closely coupled systems or figure out which one really drove the other more. It really seems to be mostly about getting the gestalt of what different areas of the program are supposed to do which then helps guide how you wrap your programming practices around that gestalt. I think that's also part of why it's easier in some sense for me to hold on to particular principles, like to keep dependency paths as clean and untangled as possible, rather than trying to stamp down any design pattern globally on every project.

One thing I'm considering doing, even if it really doesn't do much, is throwing try/catch on every controller API call. I'm considering that for enhanced readability for my error trapping but there are plenty of cases where it's simple get requests, probably unneeded, but I'm considering doing it anyway in the same spirit that everyone passes a gun around and individually checks to make sure it isn't loaded even if they just saw two or three people just do the same thing. I'm somewhat a believer in the idea that force of habit of this sort can be a good thing to develop even if I do end up occasionally try/catch wrapping something equivalent to List<B> b = 'SELECT * FROM [A].[dbo].'; return b;.

[Pattern-chaser]

It really seems to be mostly about getting the gestalt of what different areas of the program are supposed to do which then helps guide how you wrap your programming practices around that gestalt.

I think that "gestalt" is your design. Developing such things is what a designer does. Then they code them. ... Using TFD, of course.

[Papus79]

It really seems to be mostly about getting the gestalt of what different areas of the program are supposed to do which then helps guide how you wrap your programming practices around that gestalt.

I think that "gestalt" is your design. Developing such things is what a designer does. Then they code them. ... Using TFD, of course.

The trouble there - I don't necessarily know that it's easy to have that in hand ahead of time, particularly if your client is figuring out what they need from you in real time and early in the project it's up for sweeping fundamental changes. In that circumstance it starts off as mash, quite often you're explaining to them the basics of what they're trying to do, and it only starts clarifying itself gradually through emergence. The trick in that situation is build your starting block well enough where if they want to build a farm house and strap a Walmart or an eight floor office building onto the side of it they can.

IRL you'll be this guy - too often.

[Pattern-chaser]

It really seems to be mostly about getting the gestalt of what different areas of the program are supposed to do which then helps guide how you wrap your programming practices around that gestalt.

I think that "gestalt" is your design. Developing such things is what a designer does. Then they code them. ... Using TFD, of course.

The trouble there - I don't necessarily know that it's easy to have that in hand ahead of time, particularly if your client is figuring out what they need from you in real time and early in the project it's up for sweeping fundamental changes. In that circumstance it starts off as mash, quite often you're explaining to them the basics of what they're trying to do, and it only starts clarifying itself gradually through emergence.

Yes, no-one ever said (in my hearing) that design is easy. What you describe is one of the major challenges of software design. It sounds like you think you don't have time for design, a common reaction to this kind of issue, but my own experience is that you don't have the time not to design...