[-]

TangerineSorry8463@reddit

Aspect Oriented Programming, to the best of my knowledge, has been reduced to a couple of logging libraries - mostly cause it's really dependant on consistent naming of things.

(might be talking outta my ass)

[-]

PedanticProgarmer@reddit

Yeah. The usage of AspectJ has dropped significantly when compared to 2015.

For good reasons. This was a tool for „smart” devs who abused quick hacks.

No dude, it’s not smart to change what my method returns in production while keeping it untouched in tests.

[-]

Regular_Zombie@reddit

It's not largely referred to as that, but effect systems in functional language tend to be implementations of railway oriented programming.

[-]

Background-Rub-3017@reddit

Oh speaking of functional languages... they are also a fad.

[-]

chodmode2@reddit

It's used in a lot of systems that you consume everyday.

[-]

Really? One of the seminal books in software engineering (and computer science) is the Structure and Interpretation of Computer Programs. It was first published in the early 80s. It used a functional language from the 1960s...

[-]

David_AnkiDroid@reddit

Railway Oriented Programming is a teaching tool for functional concepts.

Of course, as soon as you get more experienced, you will rely on more abstract mental models for reaching your goals.

---

ChatGPT summary:

Railway Oriented Programming (ROP) is a functional programming approach to handle errors in a way that's clean and intuitive, especially for developers new to functional concepts. This approach, using a "railway" analogy, illustrates how to manage both the "happy path" and various error scenarios without cluttering the main logic.

Key Highlights:

Error Handling: It emphasizes creating a robust application by addressing validation, logging, network issues, etc., using functional techniques rather than standard error-checking logic.
Techniques in ROP:
Custom error types for clear error tracking.
Functional constructs like bind, map, and Kleisli composition for combining operations.
Tools like tee and &&& for integrating non-monadic functions and parallel validation.
Main Goal: ROP offers a consistent, reusable template for error handling that's easy to understand and maintain.
Resources: Slides, videos, and a GitHub project demonstrate ROP in practice, along with links to more on monads and error handling.

The approach, while effective, isn’t meant to replace standard monads but to simplify error handling for newcomers in F#.

[-]

rodw@reddit

Aren't a lot of "mixins" and @Annotations - the kind that are all over the Java world notably the Java Spring / Spring Boot framework - essentially AOP?

[-]

yxhuvud@reddit

That is part of the point - it never reached outside the Java ecosystem.

[-]

smors@reddit

Annotations are also used quite a bit in C#.

[-]

hungry_dawoodi@reddit

It’s quite alive in mobile development (android uses annotations aggressively)

Swifts property wrapper also seems eerily similar

[-]

rodw@reddit

I mean, it's not my platform of choice, but Java continues to be among the top 2 or 3 most widely used platforms and (depending on whose numbers you look at) still growing in popularity - and that's not even counting alternative JVM-based languages like Kotlin (and to a lesser extent Scala and even lesser, Groovy). You could do a lot worse in terms of influence than being strong in but rarely reaching outside of the Java ecosystem. I wonder how many developers almost exclusively work in Java?

And while I don't worry too much about the pedantic technical definition of "aspect oriented" so like the grandparent commenter I may be speaking out of turn, but stuff like Ruby's mix-ins and Typescript decorators feel a lot AOP to me. For that matter, raw JavaScript's prototype-rather-than-class-based inheritance orientation lends itself to Aspect-ish reuse-thru-compositon, although it definitely isn't always used that way.

Maybe there's a more precise or specific dimension to AOP that makes this declarative proxy/decorator/middleware/IoC/compositional injection-style stuff not quite true AOP but it seems to me that AOP has had and probably continues to have influence outside of Java (in general, and maybe AspectJ in particular). We just think of it more like a decorator pattern and less like a wholly new programming paradigm (as it was kinda hyped as originally).

I could easily be wrong though.

[-]

valbaca@reddit

still exists, just called middleware now

[-]

thashepherd@reddit

Spring/EJB, right? I remember that! Back in, oh, '11?

Nasty implementation, that. I always thought it was a neat concept. Reminds me of web server middleware, or maybe IoC/DI (none of which were fads or flashes in the pan at all).

Imagine writing tests without loop support or any error handling except pass/fail. And of course integration pipeline ran for 72h.

[-]

PedanticProgarmer@reddit

The entire idea of BDD is based on a delusion that there exist product owners who can write acceptance criteria. I haven’t seen it much, but in the projects where Gherkin was used it was the developers and developers only who maintained the tests.

[-]

ghmcintosh@reddit

Selenese?

[-]

We'll agree to disagree on this one. I've found Gherkin to be one of the best ways to communicate test cases with the QA Tester, Engineering Manager, Technical Service Officers and Marketing Assistants. It gets everyone on the same page so there is no ambiguity on what the Hardware / Software Integration does. The Gherkin files become part of the source code and bind to the unit tests + build pipeline. I use it at home on my hobby code and also enjoy it.

[-]

WhyIsItGlowing@reddit

Gherkin syntax is good for working out ACs, and making tests that map to them, but the likes of Cucumber, Specflow etc. aren't that necessary a lot of the time because it's straightforward to just structure tests like that without using the framework, so for people who are in the code it's not really adding anything and for those who aren't, then the level of detail people care about is encoded in the test names usually, so exporting results to something that can be browsed usually is 'good enough'.

In general, code generated from other code is pretty successful. And I'm including an OpenApi spec as code.

Code generation to avoid needing to write any code is where things fall flat.

[-]

dethswatch@reddit

Uml: I worked with some tools that'd round-trip to code and back.

The problem is just that if you were good to enough to code every day in that language, banging out the code to define the objects is actually pretty quick and doing that in a diagram always took longer.

And even as an analysis tool- seeing a diagram of the objects wasn't very useful- in any codebase, you're not using hundreds of objects, you're probably dealing with less than 10 new-to-you custom objects at a time and the ide's are good at navigating them.

[-]

a_library_socialist@reddit

Most people don't understand that coding is the fun and easy part of the job. It's deciding what to code and how to prepare for future coding you don't yet know about that's hard.

[-]

Yeah, I have sometimes refused to use prototypes in production, but you have to build up a lot of social capital with your superiors to make that kind of call.

[-]

Andrew_the_giant@reddit

1000%

[-]

Abadabadon@reddit

I've found them useful when I communicate our design / steps to a stakeholder.
They know when api "put user in person db" is invoked, it puts the user in person db. So if a new stakeholder joins the team or an existing person needs a refresher, visually its easy for them to remember the steps.

[-]

dethswatch@reddit

Right, that's a good role.

I've taken to showing the restful API (for backends because that's what I mainly do) routes and that makes things pretty clear- the devs can go and use the ide to figure out which obj's are being used from there typically.

[-]

pmirallesr@reddit

Yeah I'm using IBM Rhapsody rn, which does roundtripping. And whenever I need to diagnose an issue or learn about something, I use the IDE. It's just easier. So in the end, it does feel like the diagrams end up not fulfilling much of a role.

To be fair we only use them for structural design, the dynamics of the software are hand-coded, so the diagrams contain only a small part of the useful info.

I'd say the most useful part of codegen so far for us has been to keep patterns consistent and avoid pitfalls in C.

In fact the only diagrams that we regularly use to actually communicate with each other are draw.io diagrams made expressly to describe specific situations

[-]

dethswatch@reddit

you know what's been the most useful to me overall have been ER diagrams or -anything- that tells me how to join A to E, because while I can make a lot of assumptions- it's hard to guarantee I'm right some times.

ERwin is (is it still alive?) was ok at best and cost so much that only a dba or two ever had it.

[-]

couchjitsu@reddit

Yep, I agree.

We had Rational Rose at one point and that was more helpful to generate the diagrams from the code and you could take those in to design meetings. But going the other way was never used.

But honestly, even then (circa 2001), it was best run overnight because on the single-core pentiums, it took quite a while to generate UML from our codebase.

[-]

Kiylyou@reddit

I still use this program. It is 2024.

[-]

handsoapdispenser@reddit

In the early 2000s we did this thing where you would define your domain model in an XSD and then a build step would generate all the Java beans. That also made it dead simple to serialize and deserialize objects over the wire with type checking built in.

[-]

yourfriendlyisp@reddit

Open api? Protoc gen?

[-]

SideburnsOfDoom@reddit

Mostly I generate OpenAPi off my code, not vice versa.

And even if it was the other way around, that would be generating an API client, not the services that do the work behind the http endpoints. UML promised to gebnerate those, and now UML is nowhere.

[-]

StTheo@reddit

The problem I found with that was that it was much easier to hide bugs in the generated spec.

A couple examples my team encountered was one spec that omitted pagination parameters, and another spec that didn’t use the correct types for id (number instead of number/string union, they were migrating ids).

Hasn't it sort of moved to planning and jitting (esp in ML applications these days)?

Very fair. It's difficult for junior devs to understand and work within an environment like that without guidance and someone explicitly explaining how it's supposed to work to them up front.

[-]

Equivalent_Lie_2978@reddit

Can you give an example? I’ve never seen object behaviours simplify code in terms of the code itself. The only thing I’ve seen OOP simplify is the bridge to the domain problem in an abstract sense.

[-]

thashepherd@reddit

Sure. My specific example is damn-near-procedural code in the service layer of a backend API that factored out into tiny, testable methods on Pydantic models such that the service layer methods basically turned into one-liners. Think validation type stuff.

100% agree with your edit WRT assigning LoC to complexity btw. 3 maintainable lines are better than 1 complex line, etc. This was a clear case where the ancient ones were working too hard when there was an OO tool that provided a clearer, cleaner solution.

I also want to be clear that I'm not talking about massive object dependency graphs here. Just....cutting an object or 4 and giving them props and behaviors.

[-]

I do prefer composition but inheriting can be a good choice sometimes.

[-]

Venthe@reddit

The issue is, most developers never learned what does "sometimes" mean.

I've used inheritance maybe a dozen times over the past 5 years; everything else is far better off with composition.

[-]

EconomixTwist@reddit

Underrated answer

[-]

a-priori@reddit

Maybe it's because this is when I came of age as a developer, but the 1990s and early 2000s were a time of a lot of fads that went nowhere:

DCOM / CORBA: The idea was that you'd build distributed systems where code would be able to call functions across a network as easily as it does within the same process.

It was abandoned as an idea when people realized you can't hide the fact that you're working in a distributed system. It was replaced with protocols like gRPC, which explicitly models the network and its failure modes.

XML everywhere: The idea was that XML was a general purpose data format for representing structured documents. It became the de facto standard way of representing data, so if you were going to persist data, then it was probably going to done in XML. If you needed to exchange data between systems, it was going to be done by exchanging XML documents, perhaps via XML-RPC. If you needed to transform data, you'd do it with XSLT — an XML document describing how to transform an XML document into another XML document. These documents needed a specification to describe their structure, so you'd use an XSD (XML Schema Definition), an XML document describing the structure of another XML document. And so on. Everything was XML documents.

From this movement we got XHTML, which was an attempt to turn HTML into an XML format. It fizzled and died because it was finicky and offered no real advantages over HTML. Some things survived: Microsoft switched its Office document formats to an XML-based format in this era (the "X" in the ".docx" file extension stands for XML). We also got abominations like SAML which is still used for authenticating between systems, but has mostly been replaced with OpenID.

These days XML still exists, but is no longer the de facto standard data format and has mostly been replaced with JSON and YAML. There is similar tooling for validating documents against schema definitions for these formats, but it's not nearly as common because people realized this had limited utility.

Development methodologies: This was the hayday where various interrelated methodologies started such as "extreme programming" (1999), "agile" (2001), "scrum" (2002) and "rational unified process" (2003). These movements attempted to create a proper way of doing things, with planning processes and roles.

These movements still exist today, and many of the techniques they created have soaked into the processes used at many companies, such as regular standups and "sprints". These methodologies, especially extreme programming, also popularized the use of automated tests and code review, which were important developments for the field. But the evangelism around big, haughty "methodologies" mostly died out by the late 2000s.

[-]

andy_nony_mouse@reddit

I recently had to parse an xml document and was surprised to find that xpath parsers are dying. Those that exist are old and have security issues. Finding one was difficult.

[-]

JadeBorealis@reddit

I really wish agile and scrum would just die and disappear

[-]

a-priori@reddit

That’s fair. If it makes you feel any better, no one really, actually does Scrum or Agile, they just use the words and pick and choose a few techniques. So in a sense they have already mostly died and disappeared.

[-]

JadeBorealis@reddit

No one does "true" scrum or agile - that's why I want them dead. :)

being subjected to "scrum" psychological warfare from penny pushing heartless business douches made me have an undying hatred for the whole thing.

[-]

Live_To_Run@reddit

Yeah … all people seem to be worried about is if a story will “roll”.

[-]

davidblacksheep@reddit

Disagree with you on development methodologies. I think agile, etc, has been successful for the industry, in dividing and conquering developers and being able to micro-manage them.

[-]

varuntinkle@reddit

Isnt grpc and service architecture the dcom/corba model. Or you mean dcom/corba + failure handling is what was needed for groc..

[-]

a-priori@reddit

It’s the evolution of the idea. But the key difference is that gRPC doesn’t try to hide that it’s a remote operation. It makes it clear in its ergonomics that there’s network latency and the potential for failures, and it becomes the application‘s problem to handle these. With CORBA and DCOM it was supposed to be the framework’s problem to paper over those details.

That said this may not have been the real reason these failed. See the other thread with a postmortem on CORBA that gives an alternative explanation.

[-]

comrade-quinn@reddit

I remember these days well; especially DCOM, and I agree with your take.

While the idea was interesting, I felt even at the time it was doomed to failure. A network operation simply cannot support the same failure abstractions that represent a local operation failure, and no amount of trying to stuff the round peg in the square hole was going to change that.

The other issue with it was that you often define network operation flows differently to local ones.

For example, local operations can be chatty, calling back and forth between themselves to compose some data structure or other, they can also share memory between them in various ways.

Network operations, however, are better implemented as document based operations whereas much data as possible is collated up front and as few calls are then made over the network as possible to transmit it. In response a new ‘document’ is returned, perhaps, and then local data is updated with it.

Essentially, attempting to act as though the locality of constituent operations in a system made no difference to how they were implemented was untenable for many systems.

[-]

TraceyRobn@reddit

Yes. There was perhaps a feeling in the late 1990's that software development should become more formal, as this would make it better.

Software would become an engineering field with rules, not just designing and hacking code together.

This failed. It failed for many reasons, the top ones in my opinion were that these early attempts at formalism were mostly BS, and that it is more expensive and slower to develop software this way.

Quality costs more and most users don't care.

[-]

a-priori@reddit

I have a different take there.

The thing we realized is that engineers, especially civil engineers, don't do heavy processes because that's how you get quality. They do it because usually the artifacts of engineering work is usually hard to change and the cost of errors is high. On the other hand, in most kinds of software development, the artifacts that software developers make are relatively easy to change, and the cost of errors is low. So it doesn't make sense to treat them the same way.

That's not always the case though. You can build software the 'engineering way', and some fields do operate that way: I spent some time early in my career working as an embedded software developer on avionics systems, and that work is very process-heavy (look up "DO-178c" sometime if you want some light bedtime reading). But you make some severe trade-offs by operating that way. It's not strictly better, and the rest of the software industry is not lazy or undisciplined by not following these sorts of standards. These fields are the exception, and for almost every other case, trying to make software development 'more like engineering' is just cargo culting.

That's why you see efforts more recently in software development to lean into those differences: to make it even easier to change through processes like continuous delivery, to reduce the cost of errors through better release management, and to give developers greater insight into their systems through deep observability. That's where the software industry has gone more recently, and I think that's a more promising way of achieving the goal of professionalizing software development.

[-]

TraceyRobn@reddit

I agree with your take that most software failures are not as deadly as a bridge falling down. Oddly enough I also worked in avionics and ADA.

I generally don't think that the quality of software has improved much in the past decade. The fact that everyone is connected to the Internet and software can be patched, means that companies do little QA and patch bugs on the fly. Windows and games are prime examples.

[-]

Equivalent_Lie_2978@reddit

DCOM / COBRA, not really. BEAM does a fantastic job in this domain and is starting to grow a lot in the past few years while always allocating a big part of distributed computing

Aside from BEAM, we also have lambda functions.

The big issue with DCOM was always state management. BEAM handles this really well with the genserver/ agent etc architecture

[-]

funkdefied@reddit

DCOM/CORBA sounds a lot like some of the BEAM concurrency primitives (eg Nodes). The BEAM is making a comeback with Gleam. Hopefully it gathers more steam.

[-]

Equivalent_Lie_2978@reddit

Elixir is the front - runner with gleam still very much in early development.

BEAM works a lot more like an OS the a runtime.

[-]

montdidier@reddit

While I don’t dispute what you have said about the failure of CORBA is a widely held view I think the failure was more nuanced in reality. After reading this account on the rise and fall of CORBA it resonates more with me than the more apocryphal view.

[-]

a-priori@reddit

That’s really interesting, thanks for the correction!

Of the three I listed here, the distributed object one is the one I’m least familiar with. That’s why it’s the shortest one.

I knew it was complex from my experimentation with CORBA brokers, and then it kinda disappeared as a thing. The explanation about it being a problem of error propagation was something I heard later.

[-]

robhanz@reddit

The idea was that you'd build distributed systems where code would be able to call functions across a network as easily as it does within the same process.

This idea works fine, so long as you start with the semantics of distributed operations in the first place.

tonnynerd@reddit

Technically, there's at least 1: https://github.com/kelseyhightower/nocode

[-]

SlowMotionPanic@reddit

God yes. I’ve unfortunately been brought in to fix problems caused by no/low code many times because they just can’t scale. And, after the most basic of CRUD apps, it tend to take someone with actual CS background to know how to set things up and optimize.

Low code is at least a decent place for people to cut their teeth and see immediate results before diving deeper into development I guess.

Flowise / rivet / langflow

Powerflow

[-]

dsaint@reddit

This goes back to at least the 90s when it was called Computer-Aided Software Engineering (CASE) Tools.

[-]

dashingThroughSnow12@reddit

That one comes up big once or twice a decade.

"The S stands for simple"

One of the greatest pieces of internet tech writing ever.

[-]

CpnStumpy@reddit

Please find me the original link for this. I've tried a number of times and failed. It's so spectacular

[-]

deeetz@reddit

http://harmful.cat-v.org/software/xml/soap/simple

[-]

Empanatacion@reddit

They did mean "Protocol for Accessing Simple Objects" but I guessed liked the backronym "SOAP" better than "PASO"

[-]

appogiatura@reddit

electronic language protocol for accessing simple objects

Disagree about this being a fad, SOAP was huge for years, effectively creating services all over the place that have lived on

[-]

rodw@reddit

What domain are you working in where the pendulum has swung away from NoSQL? I feel like we're still stuck in the opposite of OP's scenario with NoSQL solutions: as you noted NoSQL has it's place but still seems to me that as an industry we're still enamoured with NoSQL (and anti-relational hype) and end up recreating a half-assed RDMS solution using tools like MongoDB where PostgreSQL would have been easier, faster and better-suited at literally every stage of development. SQL databases are crazy mature and the set-theoretic data and query model they are based on is extraordinarily powerful and widely applicable. I'd wager 7 times out of 10 a modern RDMS would be a better option where NoSQL is used in new development today.

[-]

Unsounded@reddit

For a lot of teams you don’t actually need the benefits you get from something like Postgres, solutions like Mongo/Dynamo are quick, straight forward, and don’t have a lot of the pitfalls of relational databases like pesky maintenance cycles, highly invariable reads, and queries that need to be optimized. Most systems don’t actually need consistent reads or need to have one place with highly relational data, you can use micro services and stitch the information together with caching and web calls to pull the information together and have some of the work you’d have a query do done via code you maintain.

For larger companies that’s a major benefit because you have full control, and it’s easier to scale operations wise because it offers a more predictable workload on your systems and takes ambiguity and more arcane knowledge out of the path. I agree with your stance on most uses cases being solved with a modern RDMS but most places don’t need to use the most optimal tool. Sometimes it’s better to use the more mediocre hammer and nail but stick with it because it’s simple and does the job they need to do. Other tools do exist if required, but they can become second choice for teams trying to move fast.

[-]

Fudouri@reddit

I must be old when the nosql solution is considered the simple version.

[-]

Araganor@reddit

I work in Fintech/online banking, so admittedly not exactly bleeding edge on adoption of new tech. Not one of the big banks you've heard of, but I would say we are still ahead of the curve compared to a lot of competitors.

We store almost all of our data through Microsoft SQL Server, but we're trying to migrate to Postgres as the licensing fees are eating heavily into our profits.

That being said, we actually have recently implemented DynamoDB as a resiliency layer for durable caching. But we still rely primarily on SQL for pretty much all user/account data (at least that I'm aware of). So it's not like we don't use them at all, just that our default would be to reach for relational and only consider other options for specific use cases where it makes more sense.

[-]

rdem341@reddit

SQL db has also added better support such as JSON columns.

Things like: "This function is too slow. Can you look into rewriting it?" vs "Are you sure you are writing your queries properly?" or "this overall database is really slow, what's going on?" vs "we are running a large batch process and it occurs every night at this time." to "we have no insight or say into how to shape the etl process and we'd like some because we'd like to control how the data is shaped" vs "No, it is our unspoken policy to put everything in 1st normal form if we can help it. It's good database practice and we don't trust run of the mill developers to know anything about proper data management!"

So, bad DBAs, like bad sysadmins in the past, have fiefdoms as well. And fiefdoms are in impediment to agile and the business process. As more shops had the development team owned the database processes and didn't do computation in them (e.g. mysql centric places), especially in a time when this was also the rise of MVC coding methodologies so schema design and changes were dictated by the code, the less this fiefdom was tolerated.

[-]

HowTheStoryEnds@reddit

Tell me about it.

I basically work on 2 different pseudo-legacy 'ETL' processes that are nothing more than transforming an existing badly normalized db-structure to an even more denormalized one (with 70+ column tables) because we can't control the db method the underlying structure nor are we allowed to change it to something that's more in support of the actual OLAP functionality desired and it runs on underpowered hardware. (And this underlying db engine is not cheap)

It's supercalifrasqlistic-superdbdocious Even though its application is quite atrocious. If you ignore the devs long enough you'll always look precocious.

[-]

trying-to-contribute@reddit

That really sounds painful. Sorry to hear. Hope you don't have to revisit this platform often...

[-]

HowTheStoryEnds@reddit

Honestly the code ranges from insanely old to lots of SQL. It's just the red tape around it that usually kills the soul. The standard way of life of bigger non-tech-oriented corporations.

[-]

AModeratelyFunnyGuy@reddit

Amazing write up, ty so much!

[-]

trying-to-contribute@reddit

Appreciate you. I got a friend who is a "Senior Programmer" at a Federal Bank who is mostly dealing with Oracle at his day to day. He's on the other side of the fence and I get plenty of user complaints from him as well. The majority of his clients are not developers. They are people who read reports and much of his departments responsibility is to generate thousands of reports every night. I joke that he generates paper dashboards.

He doesn't really know where these reports go to, he can't really change the report generating code because some client down stream would complain that the numbers might not be consistent anymore.

IMHO, It's not a fun place to be a DBA right now.

[-]

a_library_socialist@reddit

Just anecdotes.

[-]

AModeratelyFunnyGuy@reddit

Fair enough, ty!

[-]

Sure.

But 10 years down the road, you'll have to constantly do that weird thing with the NoSQL instance while also doing that weird join.

I know that all of these failures are technically avoidable, and I know ddb isn’t perfect either, but I’m increasingly finding it difficult to justify the use of RDBMS for any high scale or critical application that dev can feasibly used for.

[-]

northrupthebandgeek@reddit

my team specifically has a low scale ddb table with about 1k items in it. It costs $0.10/month. A comparable sql setup is $90/month.

You could almost certainly get pretty close to that degree of cheapness using SQLite (plus something like Litestream to automatically replicate changes to S3).

There's also no fundamental reason why a DynamoDB-style SQL service with DynamoDB-style pricing couldn't exist.

[-]

braino42@reddit

Sqlite is great and I've used it for a mobile app I worked on. With that said, why am I trying so hard to use sql to find a solution that meets par at best? Ddb is a simple cloudformation resource i can create/manage with the cdk wheres sqlite would require more upfront effort and an unknown operational effort.

[-]

northrupthebandgeek@reddit

What I'm getting at is that "cheap database" and "SQL" are orthogonal. You don't need a NoSQL solution like Dynamo to get a cheap database. If you don't want to use SQL then don't use SQL, but that's programmer preference driving that decision, not economics or "scalability".

(The fact that the software I write using SQL can run anywhere, not just AWS, is also pretty important to me - but obviously might not be as important to you if you're literally working for Amazon)

[-]

braino42@reddit

Point taken; I was trying to provide a counterpoint to a cost argument made elsewhere, and did not mean to imply ddb is always cheaper in every situation. If your company has the capability to operate a sql db at <$0.10/month i think that's great and worth sharing.

I think this difference in our experiences and others in this discussion is the existing environment and context these types of decisions are made in, like what you're saying at the end with sql being more portable but that potentially not being as important if you're all in on a cloud provider.

My points are that the answer to nosql or sql database when comparing scale vs cost or whatever criteria is "it depends", like is commonly said here. In order to help others, we as developers can be more specific in our recommendations and express our context that may influence that, which is difficult.

[-]

Remote-Car-5305@reddit

There's also no fundamental reason why a DynamoDB-style SQL service with DynamoDB-style pricing couldn't exist.

SQL-ity and serverful-ness are independent dimensions

[-]

deathhead_68@reddit

I find this too, a lot of people just seem to try and make dynamo work like sql and then conclude dynamo is shit. Dynamodb is THE shit when used well.

Horses for courses really.

[-]

Araganor@reddit

To be fair, I did preface my comment with "Just my perspective". I never claimed that my experience was representative of everyone else's.

I have no doubt there are plenty of shops where the pros outweigh the cons, and it's always up to the engineers to make the best determination they can based on their data and use case.

[-]

donjulioanejo@reddit

Yeah NoSQL was definitely a fad, but it also has some pretty legit use cases.

Put relational OOP data in a normal SQL database. Then put unstructured or arbitrary data in NoSQL like MongoDB/DynamoDB so you're not storing megabyte-size json blobs in Postgres.

[-]

frontenac_brontenac@reddit

My understanding is that DynamoDB isn't exactly great at large blobs. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ServiceQuotas.html#limits-items

[-]

abe_mussa@reddit

Oh god having flashbacks to early in my career, using NoSQL instead of SQL for a new project. Didn’t really make sense, given the experience of the team and the requirements of the project itself

i just remember when all that stuff started coming into fashion in like 2009/2010ish...i was working in agency-land and was pretty productive during the time period after flash died with CakePHP (then Laravel) + vanillaJS..

myself and another senior dev there were pretty productive with PHP (yeah not sexy, but it wasn't wordpress either), but the younger devs we worked with who thought wearing fedoras was a good look also really loved coffescript and mongo, which alone made me kinda reject it for a while haha

at the time, i was still used to javascript being a pain to work with because i remember the "DHTML"/Web2.0 era, and the idea of serving a website with javascript instead of like Apache or something proven to work for years seemed nuts to me, but i've evolved my thinking slightly over the years :)

[-]

dustyson123@reddit

Ok similar experience and thought process, but coffeescript was actually very cool and solved a lot of the problems I had with JavaScript at the time. There's a reason a lot of coffeescript constructs like arrow functions and destructuring made it into ES 5+.

[-]

Material_Policy6327@reddit

True. The startup I was at tried to swap to it and they quickly realized schemaless didn’t mean easier

[-]

inkydye@reddit

I mean, it came out of shops like Google, which genuinely needed a scale that wasn't reachable by existing RDBMSs, and at the same time didn't need some of the standard features. For them, it solved a problem.

Then everybody wanted to act like they needed the same problems solved.

[-]

fortunatefaileur@reddit

My related theory is mongo just didn’t enable auth by default and that became the critical feature that won mindshare vs everyone having to remember how to edit pg_hba.conf on their workstation.

[-]

SideburnsOfDoom@reddit

AWS DynamoDb and Azure C0osmosDB get used a lot. They're noSQL. They're not Mongo, but some similar ideas.

But yes, there are cases where they work really well, and cases where you want SQL. They will not make SQL obsolete.

[-]

pydry@reddit

there are cases where they work really well

There are cases where they work acceptably and there are cases where they fail horribly.

Ive never heard of a use case where mongo was better than postgres.

[-]

Ghi102@reddit

In our case, we have a subset of data where there are essentially no relational relationships in-between the data. We never do anything like a "join", we don't even compare pieces of data in-between each other. They are all essentially independent pieces of information that get updated separately. They mostly have the same format, but sometimes have differences that would make it hard to manage in a regular SQL database.

This is pretty much the ideal case for going with NoSQL database and it works quite well. That's not to say that we are not using SQL. A big part of our domain is relational and we are using SQL for that. But a significant chunk is quite clearly non-relational and would not be served well by a SQL DB.

[-]

ChicagoJohn123@reddit

Lemme ask you, do you then reassemble all the data into a warehouse so you can do analysis?

[-]

Fun_Hat@reddit

Not who you asked, but nope. That's what Presto is for. No pre-assembly required.

[-]

ChicagoJohn123@reddit

But then you’re just doing full database queries.

[-]

melikefood123@reddit

Much like Redis? We used that to store a ton of key value pairs, and misc data outside of our relational db.

[-]

SideburnsOfDoom@reddit

ve never heard of a use case where mongo was better than postgres.

I think it's deceptive to start the argument with "they work acceptably", "they" meaning NoSql database in general; and then focus on how bad Mongo is.

I mean it's is, but it's not all of "them". We knew to avoid it in favour of the AWS and Azure options mentioned above. And I have definitely come across cases that fit DynamoDb better than postgres.

[-]

pydry@reddit

Cosmos is basically Microsoft's overpriced hosted mongo. Same applies to that.

[-]

Ethesen@reddit

It also has Cassandra API (and more).

[-]

ChicagoJohn123@reddit

I’ve never met someone who was happy about their decision to use dynamodb.

[-]

deathhead_68@reddit

I've used DynamoDB for loads of stuff both in startups and for my current FAANG-adjacent job. I find a lot of devs misuse it tbh, but when its used properly its incredibly powerful

[-]

Fun_Hat@reddit

I find a lot of devs misuse it tbh

This. My manager is former Amazon and she said that even there is was widely mis-used. They had to have trainings on how to correctly use it.

[-]

Ilookouttrainwindow@reddit

I think "nosql" databases are great, but they are an addition to SQL, not a replacement. Just like SQL can't solve every problem out there. I do remember mongo declaring how "shit" all of SQL was, how dinosaur it was. Look at the latest version - schemas, acid transactions, all of SQL stuff. But can it do join yet? Have they finally done away with map/reduce? Then there's redis - little beast that saves everything.

[-]

nt2701@reddit

We even have a certain decent sized product that currently is using NoSQL DB planning on moving back to SQL DB. 🧐

[-]

allKindsOfDevStuff@reddit

It was funny when people tried to backronym it years later and say it stood for “Not Only SQL”

[-]

Do you know of any useful resources comparing performance of relational vs non-relational databases at different sizes of data stored and queried?

[-]

TimeToSellNVDA@reddit

Okay, I'm going to start the flamewar 🔥

Test-Driven-Development in its "purest" sense
Extreme Programming
Pair programming in its "purest" sense

I want them to die with in a fire, and I don't hear people talk about them much any more - other than ironically. It's how managers think you can get more or better quality done if you add one more engineer.

[-]

optimal_random@reddit

TDD is only awesome for testing the Sum functions or other trivialities always shown in examples.

Once your code has network calls, database data fetches, and all sort of abstractions, then the whole concept falls on its ass.

Don't get me wrong, Unit and Integration testing is really important to ensure the quality of software, and I use it extensively. But the whole TDD gospel is just unbearably ridiculous.

[-]

MargretTatchersParty@reddit

There is a limit to how far you can go with TDD and pure unit tests. The resource calls _should be_ abstracted away. Having good unit tests shows that you're in that situation and forces you to limit the mixing of unit testable and non unit test able code.

[-]

frontenac_brontenac@reddit

Extreme Programming is still the #1 way to ramp up new products and new teams when you have in-house expertise that isn't already in the software teams' heads

[-]

thashepherd@reddit

TDD is a good tool to have in the ol' mental toolbox, just don't expect that to be the default programming style.

Ditto pair programming.

XP was before my time, I always saw it as sort of a proto-Agile: is what you make of it.

[-]

HighBrowLoFi@reddit

Absolutely right. These approaches are great for training junior developers (and even then only part of the time), but otherwise are not only unproductive, but miserable for many developers. The success of XP and Pairing often implicitly rely on extremely opinionated and predictable development. You can get much better bang for your buck by just empowering a team collaborate effectively and then give them space to be productive

[-]

TheWhiteKnight@reddit

Came here to say this. TDD was interesting, tons of people that had no idea what it was would say they were doing it, but I have yet to see anyone actually do it anywhere.

I stopped telling people that just because they're writing tests doesn't mean that they're doing TDD. "Yeah, ok".

XP is the other one. I joined a company with extremely smart folks but while there were pair stations, they were rarely used. Our perforce commits had to have a "pair" assigned in the commit message. But they were just reviewing the code. Not pair programming / XP.

Still, we had a bulletproof testing strategy. We had tests that tested our test framework (but what tests tested the tests that test the test framework? LOL). Very thorough, learned a lot. Our tests would create their own Jira tickets, upload log files to them automatically, and assign them to the triage person for the team responsible for that area of the code. Tons of lab machine automation. Spin up various OSs on specific machines with various RAID configs, build the code on that machine, run the tests, capture log files, open Jira tickets, tear down the machine, and put it back into the pool for other tests to grab.

[-]

EarthquakeBass@reddit

TDD is an interesting idea but I always kinda got the impression it ends up over fetishizing tests and trying to cram everything into a test to the point of monotony when that’s not always the right tool.

XP I never tried but seemed to be a way to try and spice up a process that’s inherently fairly unpredictable yet boring.

Pair programming personally I kind of hate. I mean I’m all for hopping on with colleagues from time to time but the idea of two people sit there and one person drives is (1) exhausting because you are constantly being monitored, (2) inefficient because speaking to communicate is far inferior in bandwidth to writing, (3) inefficient because, well, those two people could be doing things in parallel. I have a feeling pair programming caught on largely to sell more seats for consultants — after all, why bill out one competent programmer when you can bill out one competent programmer and one incompetent programmer for twice as much.

[-]

Non-taken-Meursault@reddit

I fucking hate pair programming. I get it when you're new and getting used to a new codebase as a junior dev, but its benefits wear out quickly and it ends up being one dude programming and the other one chiming in occasionally while mortally bored.

[-]

OblongAndKneeless@reddit

It doesn't work when the bored one has ADHD. They're off doing something else in their head.

[-]

DiligentComputer@reddit

Pair programming without an intent to either a) investigate a tricky bug together and learn as a pair (which you could argue isn't actually pair *programming*), or b) have one party actually intending to teach some part of the system or some concept to the other, is actually a downgrade of team productivity. In those two cases, though, I've found it to be quite a good technique.

[-]

CubicleHermit@reddit

Pure TDD is awesome for certain specific kinds of greenfield business logic or infra code. Since working with someone who was NUTS for TDD about 10 years ago, it's been absolutely amazing for three very specific, very critical classes in that time.

Can you provide a source for that claim about Amazon?

I must have missed something.

[-]

WearMental2618@reddit

Ring. Alexa in everything. They also host the alot of the iot cloud (azure too)

[-]

ripreferu@reddit

Ring and Alexa are services for customers, but what about business to business uses?

The manufacturing company, I work for, relies on IoT sensors and creates its own mesh. They are probably not using azure, nor Amazon for this.

[-]

hashtag-bang@reddit

I think this is probably bigger than most of us know about. Like more popular in traditional industries rather than say it being a smart home thing.

[-]

A lot of work to setup the semantic web, but what kind of value did it bring? I can't recall any 😅

[-]

Familiar-Flow7602@reddit

That's because there is no one Person or Bank or Money but it depends on perspective you are looking at it

[-]

“Web 3.0 (not to be confused with Web3)”

[-]

PM_ME_SOME_ANY_THING@reddit

You should check out the first line of that Web3 link. Kinda dumb that since one didn’t catch on they just reused the name for something else.

[-]

gajop@reddit

The Semantic Web, yeah. I did my master thesis on it. Lots of cool tech around it (especially logic reasoning), but the core premise is problematic. Companies don't want to openly expose all this data to the public, and allow you to navigate/parse it how you will. FB isn't going to expose their user network as a FOAF, because their userbase is extremely valuable and they want to be in charge of presentation.

hmmnda@reddit

Ah yes the "Semantic Web" with all the subject predicate object promise of making the whole web easy to understand for machines.

[-]

northernmercury@reddit

Using a java cross-platform UI framework.

Speaking of security vulnerabilities it feels like Macromedia/Adobe Flash is what originally ate Java Applets' lunch, a couple of years before raw HTML/CSS/JS became rich-/dynamic-/productive-enough to address almost any use case an applet might have been used for.

For that matter Java as front-end GUI framework at all seems pretty rare today (with a few notable exceptions).

[-]

fuzzynyanko@reddit

Speaking of security vulnerabilities it feels like Macromedia/Adobe Flash is what originally ate Java Applets' lunch

Agreed. YouTube especially began to take off. Flash crashed a lot, ate up RAM, gave us annoying ads, and pretty much followed in Java's footsteps. People made jokes about it. SPOILERS: Dragon Ball Z Kai Abridged 2 .

Flash for game making was actually pretty cool.

[-]

TangerineSorry8463@reddit

I'm so glad that Apple didn't invent TypeScript cause now we would be dealing with googling AppleTS and getting vintage ancient Java bullshit.

[-]

ScientificBeastMode@reddit

Lmao that would be hilarious and horrifying at the same time…

[-]

davy_crockett_slayer@reddit

Java applets on the web.

It went on for a few years before real developers started rewriting things without XML and showing how it could be simpler, faster, and less fragile. The speed difference from dropping XML was an easy win in so many optimization exercises.

[-]

wvenable@reddit

In way though, thank god for XML because it seems to have replaced a whole hell of a lot of proprietary binary formats. Even Word documents are XML now.

Eh, XML is still a perfectly good way to structure data, and honestly better than some of the replacements.

The problem with XML was that it got turned into this bizarre panacea way outside what it should've been used for. XML database, XML structured code, XML dependency injections (Spring XML configs.... **shivers**).

Lots of fads _around_ XML, for sure.

[-]

latkde@reddit

XML was for sure shoved into a lot of places where it shouldn't be, but I think its main problem is that the data model doesn't fit the data model of most programming languages:

in most PLs, an object has fields
in XML, a node has attributes and children

You can define various mappings between these worlds, but it will never be as seamless as an object–relational or object–JSON mapping. So XML implies a lot of unnecessary complexity compared to alternatives.

Where XML is absolutely fantastic is as a syntax for custom text markup languages, but that is such a niche use case.

[-]

carloscrmrz@reddit

yes, data models with XML are weird. Currently working with international wires through SWIFT and a clear example I have is the Settlement Amont & Currency.

For some reason the model for that is having your Currency as an attribute and the Amount as the node’s value which is not horrible but just doesn’t feels quite right.

[-]

ProfBeaker@reddit

as seamless as an object–relational or object–JSON mapping.

By "object-relational" you mean that thing which has entire mapping frameworks to try to hide the complexity?

And by "object-JSON" you mean that thing which has huge serialization libraries, and still struggles with advanced concepts like dates?

They're simpler in some ways, but "seamless" is a wild overstatement, IMO.

robhanz@reddit

As I said in another comment, XML is just a horrible misapplication of tech (specifically as a subset of SGML). SGML is a document markup language, and using it for a data format is just full of impedance mismatches.

[-]

username_or_email@reddit

Thank god for that, I fucking hate xml

[-]

magical_midget@reddit

We still carry the same pains, json, yaml, etc are alive and growing.

I'm not sure they were ever mainstream popular but DAE remember Java Aglets? "Movable software agents" that could serialize their run-time state and move to a new execution environment for reasons that were never very clear to me.

I guess the generic term is maybe mobile agenr

[-]

alfalfa-as-fuck@reddit

Jini!

[-]

CallNResponse@reddit

This thread is a lot bigger than I expected.

Did anyone mention Virtual Worlds yet?

[-]

Zenalyn@reddit

Blockhain

[-]

CS_Barbie@reddit

Yep

[-]

to-too-two@reddit

Is this one a fad?

I know it was a buzz word but isn’t there no crypto without blockchain? And cryptocurrencies are certainly here to stay.

[-]

mezolithico@reddit

It's still in its infancy, and there is some interesting use cases, especially in the finance world. Will it survive? Nobody knows.

[-]

backdoorsmasher@reddit

Genuinely question, but what are some good use cases for it?

[-]

mezolithico@reddit

It eliminates counterparty risk. You could use it at the backbone of equities exchanges, instant stock trade settlement, prevent naked short selling. It can be used for bond payments. Cheaply sending money internationally for inter bank transfers. It could really make insurance more efficient. For instance life insurance policies. A trusted org like the social security offer can send a list of deceased folks ssn, and a contract would auto payout death benefits.

[-]

[-]

I was coming in here to say web3.0

[-]

rodw@reddit

The worst part of the "web 3.0" moniker is that it sure would have been useful to use that label for the LLM/generative AI web. It feels like not enough normies recognize "web 3” to call this "web 4” and the generative AI influenced web is a LOT more closely aligned with the web 1/web 2 level of paradigm shift than blockchain stuff.

Calling it web 3.0 was stupid to begin with. It's largely infrastructural at best. Even in the wildest crypto-bro fantasy blockchain itself was never going to be as transformative as these other examples.

[-]

Eric848448@reddit

I’m surprised this wasn’t the top comment.

[-]

BrokerBrody@reddit

Because Blockchain was more buzz than actual implementation.

Many corporations actually tried to implement tech like NoSQL and goodness it was terrible for nearly all but niche use cases.

[-]

This makes no sense to me. I find TDD is even more valuable if the requirements are frequently in flux. It is a demonstrably true description of the current behavior.

And I HATE updating code that doesn’t have tests, it takes 10x longer because I have to infer all of the possible consequences.

Do you seriously have a different experience?

[-]

ImSoFuckingTired2@reddit

> I find TDD is even more valuable if the requirements are frequently in flux. It is a demonstrably true description of the current behavior.

A demonstrably description of the desired behaviour is, well, just a description of it. It does not need to be written in the form of tests, nor it would be useful to other stakeholders if so, since most are non technical.

> And I HATE updating code that doesn’t have tests, it takes 10x longer because I have to infer all of the possible consequences.

I don't follow. Are you suggesting that you use tests only as proof of requirement fulfillment? Then either your tests are incomplete, or your requirements are always complete, which I highly doubt.

[-]

abe_mussa@reddit

Are we talking about having unit tests in general here? Or TDD?

I like writing the test first since it’s a place to think ahead about interfaces of things, expected output etc. It’s not simply a chore to validate code I’ve written, it informs the implementation itself

Whether you think unit tests are necessary or believe they make life harder is a different issue, in my opinion. But I’ll share my own opinion on that either way

I disagree that constant changes make it pointless. If anything, having tests helps us ship faster with more confidence. If you’re rapidly making changes, having that quick feedback that you’ve not accidentally broken another requirement is useful.

If small changes are causing significant test rewrites every single time, I’d question the way the tests are written. Do they care about too much implementation detail?

I think you’re missing the point with the demonstrably true point. It’s a description of the current requirements - with the implementation validated against.

[-]

MagicianSuspicious@reddit

The benefits of any practice are "hypothetical" until one spends the required effort to gain facility with the practice. Personally, I've found the benefits of practicing TDD to be very non-hypothetical.

"Agile" is not a practice.

[-]

ImSoFuckingTired2@reddit

> The benefits of any practice are "hypothetical" until one spends the required effort to gain facility with the practice.

I agree with that.

But I have found that, when a practice is both hard to adopt and contested by many, it does not matter how beneficial may it be for some, since it won't become widespread.

> "Agile" is not a practice.

The practice of agile is, well, a practice.

The framework, or methodology, or whatever word you want to use, is the idea of it, and on paper, agile sounds great. The practice, or implementation, is abysmal, though. Again, it does not matter how good the original intentions were, or if a minority has implemented it correctly and reaped the benefits, if the vast majority out there are essentially using waterfall with extra steps.

[-]

MagicianSuspicious@reddit

But I have found that, when a practice is both hard to adopt and contested by many, it does not matter how beneficial may it be for some, since it won't become widespread.

My primary goal is to be effective, and help organizations that I work with be effective. My experience is that TDD is a key part of fulfilling each of these goals. Does it take a lot of practice? Of course.

Frankly, I think most people find TDD daunting because it exposes gaps in software design skill. There are two ways out of this: gain design skill, or give up (and optionally blame TDD).

The software construction skill and discipline of the median team in this industry is, frankly, terrible, at least in part for the reasons I outlined above around experience:

The experience balance skews toward the beginner. An example is this subreddit, which defines "experienced" as "3 or more years". A developer with 3 years of experience is still in the beginner phase of their career. I wonder if telling someone at that stage of their career that they are a "senior" makes them less likely to acknowledge that they are still in the beginner stage, and thus stunts their growth.

It takes a lot of practice to gain facility at building software. For me personally, TDD accelerated that process greatly. I've also seen it accelerate that process for others with whom I've worked, and those that I've mentored and managed.

re: "Agile" as a practice:

There is no standard "implementation" of "agile". It's just a grab bag of ideas and ceremonies -- mostly from scrum -- that are commonly applied to project management.

I do agree that many organizations have sprinkled "agile" ceremonies atop wasteful/comfortable practices, and miss many opportunities for improvement as a result.

But I think, on balance, software project management now is generally more effective than pre-widespread-agile adoption practices. I was over a decade into my career when agile gained popularity, so I worked in actual waterfall shops, wrote detailed design documents with the best of them, worked with throw-it-over-the-wall QA teams, shipped software on floppies, studied Steve McConnell's books about software process, etc. before ever trying "agile". I really do think that what we have now is better than those days.

[-]

ImSoFuckingTired2@reddit

I'm so glad.

I interviewed at a company recently where the CTO was a TDD nut. Didn't get the job because I didn't buy into doing TDD to the exclusion of everything else.

[-]

sharptoothy@reddit

Same, but for Windows XP: RY7B2-K9QQ4-H9H34-7DPX9-XQ7MG

[-]

Venthe@reddit

XTQJC-T8CCG-4BWVT-8TG6X-MX9QG

Last time I've used it/typed it was maybe 15 years ago or so. This shit is burned into my memory.

[-]

hot take, but this is purposeful.

I think there was a quote from microsoft "if they're gunna pirate, we want them to pirate our stuff"

I use functional programming at least weekly, but probably several times per week during some weeks.

I use python and rust. Probably 70% of my functional programming is python list comprehensions.

[-]

Flashy_Current9455@reddit

Some parts have been imported through Kotlin and Swift

[-]

Flashy_Current9455@reddit

Some parts have been smuggled over in Kotlin and Swift :-)

[-]

alfredrowdy@reddit

thin clients

[-]

comrade-quinn@reddit

Really? I feel it’s the other way round. Mainframe is fat client, that’s the OG of mainstream remote client computing. Then things like desktop apps backed by servers came along but have increasing been replaced by websites.

Websites were originally always thin clients. The last decade or so saw a trend towards fatter clients in the form of SPAs but that is now being reversed with a push to simpler, leaner HTML where possible and a push to SSR where not.

Mobile apps of course are fat clients, but like desktop apps, I think they exist as they’re forced to. For example, Windows encouraged desktop apps as they created vendor lock in for MS.

Apple does the same as iPhone would be goosed as a cash cow were it not for the App Store. Were Apple to embrace PWAs, I think you’d see a bigger uptake in them rather than Apps.

This is because, fundamentally, thin clients reduce work in terms of duplication and make updates to the system easier. As such, I think when all things are equal, they’re the default to which we as a tech community will gravitate. It takes something to push us away from that (network latency, walled gardens, technology limitations etc), and that does happen frequently, but whenever such obstacles are removed over time; we centralise again. And that looks like thin client.

On the other hand, plenty of big business survive purely because of the data they can gather and sell to advertisers.

[-]

sobe86@reddit

Sure, and some companies genuinely make money from any fad you can think of, they're fads because more people/companies bought into them than was warranted.

[-]

epelle9@reddit

Big data is as much of a fad as GPS. It’s not a fad.

It’s in basically any big software/hardware you use, people don’t pay much attention to it anymore, but it’s important for most apps you use daily.

And it wasn't the tech that made them profitable. It was price hikes

[-]

ddarrko@reddit

Uber are profitable.

I'll say "Design Patterns". Like, it's still a real thing, and you'll still frequently reference a known pattern when planning a project etc... but in the mid 2000s, there was a fad. Interviewers would ask questions like "what's your favorite design pattern" with no context for what kind of problem you're solving.

I worked at a big company that had an architecture committee and any time you built a new service you had to present it for architecture review, and there was a blank where you had to list at least 4 design patterns you used. Again, no context, just "yes, this has some Singletons, an Observer, and a Chain of Responsibility"

On early-to-mid-2000s interviewing fads, those stupid brain teasers like "how many bags of cheetos can you fit on a 747" were all the rage at the same time because some guy from Microsoft wrote a blog post about how he liked to ask them.

[-]

My hot takes:

Expert Systems (never really worked, replaced by modern ai approaches).

Semantic web (I have never seen an actual concrete proposal of how this would actually work. Kinda morphed into web3).

Flashy_Current9455@reddit

Unit-testing

[-]

ctorstens@reddit

You don't unit test? I think of this as foundational.

[-]

Flashy_Current9455@reddit

Mostly kidding about it being af fad. But I haven't actually worked in any codebases with much unit-testing beyond specific low-level parts of the code

[-]

Ok_Raspberry5383@reddit

You sound like a junior who works as a software engineer at their mother's cleaning company

[-]

Flashy_Current9455@reddit

Oh, slam! You got me.

But that's the spooky part...I'm way senior and talking from experience from many companies

[-]

Ok_Raspberry5383@reddit

And you don't write unit tests? Sure... Senior can mean a lot of things...

[-]

Flashy_Current9455@reddit

Yes, most of the time it just means that I'm old :-D

There plenty of interesting discussion to be had about unit-testing, but I don't think this thread is suited for it. I mainly started the comment thread as a light trolling :-P

I think the top comment about "TDD" is the more serious and interesting version of my silly comment

[-]

serial_crusher@reddit

I could see an argument that the zealousy of "unit tests" and "integration tests" being different things was kind of a fad. Like just write the appropriate test that makes sure your stuff works, bozo.

OOP

[-]

anthropaedic@reddit

Agile

[-]

Venthe@reddit

Hard to say it's a fad. It's still the best way to develop software product, bar none.

What was a fad, was to "introduce" agile without changing anything at all; then surprised pikachu it did not deliver. Shocking.

[-]

RangeSafety@reddit

Microservices, that makes everything more complex and expensive that it should be.

Cloud, in other word someone else's computer.

LloydAtkinson@reddit

Or as it’s always been called: Service Orientated Architecture

[-]

bart007345@reddit

They are alive and kicking.

[-]

RelevantJackWhite@reddit

They are alive and auto restarting!

[-]

Torch99999@reddit

Hopefully not for much longer.

[-]

a_reply_to_a_post@reddit

Y2K consulting

AR driven e-commerce

NFTs

[-]

Ok_Raspberry5383@reddit

Y2K was a very real problem... It was thanks to enormous efforts years before that meant there was no melt down

[-]

Quantum computing

[-]

Ok_Raspberry5383@reddit

Still very much in development, this is highly experimental though. It's never been adopted though so I don't see how it could be a fad

[-]

Prog9999@reddit

We had a module on functional programming in my degree using standard ml.

Then-Boat8912@reddit

Enterprise Service Bus

[-]

valbaca@reddit

No Code in all of its iterations, including the current one. Surely this time we'll replace coders...and not end up just needing more coders to maintain the mess the tool split out.

SOAP COBRA XML J2EE Applets Flash UML

Custom AI chatbots being shoe-horned into everything.

Oh, sorry, you said “past.”

[-]

VB ? :)

[-]

mrequenes@reddit

I used to work on RAD (Rapid Application Development) tools back in the late 90’s

In the early 2000’s, a “NextGen” platform

Only NoSQL can be “web scale”. XML, SOAP, CORBA, TextMate.

[-]

Qkumbazoo@reddit

Graph databases, it was hyped up precovid and pushed as a replacement for any use cases, including acid-compliant Db's. Where is GraphQL being used today?

[-]

No_Technician7058@reddit

idk i think neo4j and pg AGE are both pretty popular at this point

[-]

papawish@reddit

I've used Neo4j recently for a perfect use case.

npiasecki@reddit

After doing this for 20 years, I would say all of it. All of it!

We can build a bridge that lasts 50 years but we as an industry are incapable of building anything that won’t be barely-compilable trash after 10.

VB6, CORBA, CVS, ActiveX, ClickOnce, Applets, FoxPro, Delphi, SOAP, XML, SVN, .NET Framework … when can I get off this bus?

I am so tired of rewriting for API deprecations that basically do the same thing but different, I guess because the new batch of devs didn’t understand how the old one worked.

I spent the early part of my career rebuilding Silverlight apps as web apps.

It wasn't a horrible idea for its time given that Java applets and shudders Flash websites were a thing, but its time came and went.

At one point I think Netflix's web player was Silverlight.

[-]

3ABO3@reddit

Oh man I totally forgot about it

[-]

Repulsive-Philosophy@reddit

Oh god...

[-]

MaCooma_YaCatcha@reddit

While i agree with majority, blockchain tech is not retarded. Elections can be implemented on blockchain but we are not mature enough (ring signatures). Also NFT got abused but real world use case are contracts, especially loan contracts, that can be enforced. This brings us options and futures. All this got overshadowed by money-grabbing-scam-projects.

We could also save signatures of documents on blockchain so we can verify validity.

I see kubernetes going this route. it is following the pattern of a fad.

- everybody and their mom has to have it

- suddenly it's on every fucking cloud infra job app

- people trying to bandaid it in places it really shouldn't be used

probably gonna get some hate from cloud folks but that's ok

maybe it just me, but if your problem is killing ants *you don't need a bazooka for it.*

I see it as a red flag when I see a small series A / B startup trying to immediately use kubernetes. like seriously why are you over complicating things so damn early...?

[-]

Which_Grass_9043@reddit

So many: - reactive programming - full stack JavaScript - functional programming (for all the things) - serverless architectures taken to an extreme

Although it’s more interesting to think about the things I thought were fads, and was wrong about: - docker - golang - …probably more I’m forgetting about

Until one day, after years, everyone collectively seemed to wake up and acknowledge that it sucked. Then people would openly mock webforms and say how you should use this other new cool thing.

[-]

rudiXOR@reddit

Model-driven software development
Hadoop
SOAP
Enterprise Service Bus
Semantic Web
Microservices (still happening)
Agile (debatable)

[-]

nekokattt@reddit

Several of these are debatable

[-]

rudiXOR@reddit

Well true but every single one was overhyped.

[-]

BigRedThread@reddit

For all the hype blockchain and crypto were getting (remember the metaverse?) even a couple of years ago, it has almost completely fallen off the map since it just did not have a strong enough case for it

[-]

metadaddy@reddit

I’m surprised nobody mentioned WS-*, aka “WS-Deathstar”.

At one point in time, Microsoft tried to persuade developers that applications should exchange XML messages with schemas spread across about a dozen different specifications: WS-Notification, WS-Topics, WS-Addressing, WS-Federation, and all too many more.

[-]

sawser@reddit

Block chain.

A couple years ago my bosses asked if we could implement it and I explained it was just an immutable database, and that we should just have good permission controls and audit controls, along with regular backups to compare with instead.

[-]

EarthquakeBass@reddit

I think there was a sense at one point that containers would take over all of the entire SDLC and everything would be dominated by Docker. Instead it ended up being a lot more fragmented and many of us still develop natively, outside of containers then deploy to them because the problems with local dev never got fixed.

[-]

fogcat5@reddit

not really a fad, but some technologies change and things are profitable or not like RISC CPU which looked liked the future back in the early 90s, or bubble memory which is just around the corner for the last 30 years, or holigraphic storage or tape storage like 9track but super high density with lasers.

[-]

yojimbo_beta@reddit

Object orientation

Antique-Echidna-1600@reddit

Modern tech stacks are a fad. lol

[-]

Codeless programming. That was so awesome.

[-]

Regular_Zombie@reddit

Some things are 'fads' because they're new and shiny and enjoy a surge of popularity before fading: block chains, NFTs, noSQL.

Buying your own hardware way cheaper than the computer/time rentals? You do that.

You wanted to have the capability of a mainframe but it’s too expensive, and you have a lot of smart CS peeps assure you they can build a better system using a cluster of PCs? You let them try.

Database engine everyone is using can’t keep up with the volume you had? You change it to something else.

Your app clients doing a bunch of over fetching because your API endpoint people can’t keep up with the backlog for specialized endpoints for every single screen? Hope you got an architect that can fix that, so clients gets exactly what they wanted while freeing up the backend team’s backlog.

I intentionally didn’t mention any names because the reason is more important than what it is. Any sales brochures touting the virtues of a system beyond those original reasons never mattered, which is why everything seems “faddish.”

Manager that just understood famous company did something decided they should too, because that’d make their company like that one somehow. Most of them failed to understand the original reasons why it made sense there, so it gets implemented, shown to suck for their specific use case, and it’s eventually scrapped.

Other people that had similar reasons uses those exact technologies happily without any issues. It’s not a “fad” for them.

[-]

srb4@reddit

CORBA

[-]

MagicianSuspicious@reddit

Class-oriented design, and in particular implementation inheritance.

[-]

WholeRazzmatazz7658@reddit

I think all of those things are super useful and work well when they're chosen as the right tool for the job, but this industry has a tendency to prescribe them as a cure-all for every problem space. I would add JS frameworks, functional programming, object oriented programming and I think we'll look back on generative AI in the same way. They're all great in the right application, but they aren't going to solve all of the world's problems.