Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My 20 year career is technical debt or deprecated

blog.visionarycto.com

Post reply on HN
Print view View original

541–550 of 585 posts

Re: My 20 year career is technical debt or deprecated

#541

Post by tcfhgj »

ravenstine wrote: post #498
klibertp wrote: post #281

Earlier quoted context omitted.

Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that simply documenting all the bad things in a single codebase (along with explanation why they're bad) took me a month. It's tiring and mentally draining to do this: every other line of code you read makes you go "Why. Please, just tell me why anybody could ever…

The problem with Uncle Bub is that his views only work in sync within very limited situations such as hobby coding and small projects by a handful of developers who are starting on the same page. A lot about Uncle Bub's teachings and FrAgile isn't practical in most of the real world besides a minority of outlier stories (and the problem with those stories is they don't track whether practices continue working long te…

If you only write comments about intention, your code seems self descriptive, doesn't it?

Why don't you write comments describing what the code does?

> and even they often don't know because... surprise... nobody wrote anything down!

Well, read the code

Re: My 20 year career is technical debt or deprecated

#542

Post by tcfhgj »

wruza wrote: post #540
tcfhgj wrote: post #538

Earlier quoted context omitted.

I see a benefit from having this options container: you can have a central place to set the options and then only pass down the decoder and the user of the function doesn't have to bother with the configuration

You can always pass a closure.

Well, that's basically the same

Re: My 20 year career is technical debt or deprecated

#543

Post by cultureswitch »

klibertp wrote: post #409
Izkata wrote: post #400

Earlier quoted context omitted.

> Don't forget all the getters and setters merely updating/reading a variable > and in the most verbose/inflexible ways possible It's actually extra flexibility meant for two things: being able to override the getter/setter in a subclass, and keeping a consistent interface so users don't need to change how it's called if there was a refactor that adds something to the getter/setter (such as transforming the value bec…

> these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nat…

I think it's strange that people complain about the verbosity and boilerplate getters and setters in Java when this is entirely a non problem, provided your code is well designed.

If your class has any setter function, you're doing OO wrong. Mutating an object should 1) only happen if you have a very good, inescapable reason; 2) never be exposed directly to code outside the class, including children. If your class must have a mutating function, it should be a high level operation, not "set". If it really is "set" then that implies the field being set isn't a part of that object in any real sense.

A well designed class might have a couple of getters, but the inclusion of getters is a deliberate decision to allow client code to see the internal state.

In other words, blame the IDEs for the idea of auto-generating getters and setters. The language itself did a decent job of protecting class state.

Re: My 20 year career is technical debt or deprecated

#545

Post by kazinator »

cultureswitch wrote: post #543
klibertp wrote: post #409

Earlier quoted context omitted.

> these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nat…

I think it's strange that people complain about the verbosity and boilerplate getters and setters in Java when this is entirely a non problem, provided your code is well designed. If your class has any setter function, you're doing OO wrong. Mutating an object should 1) only happen if you have a very good, inescapable reason; 2) never be exposed directly to code outside the class, including children. If your class mu…

OOP is routinely used with stateful, mutating objects; it has been hailed as a good way to manage that paradigm. If mutation is bad, so most objects don't mutate, you're talking about a functional niche in OOP, not mainstream OOP.

A class may need a setter function for some boring, pragmatic reason like, say:

- the language doesn't have keyword parmeters: constructors have only positional parameters

- the class has a large number of properties.

- most users set only a small subset of the properties, defaulting the rest. (And you can't easily predict which subsets are popular enough to get their own constructor variants.)

In that situation you might want to just construct the object in two steps: default everything and set a few selected properties (and then don't touch them). It's de facto immutable, just not around construction time.

Re: My 20 year career is technical debt or deprecated

#546

Post by raverbashing »

cultureswitch wrote: post #543
klibertp wrote: post #409

Earlier quoted context omitted.

> these Java conventions started when no such thing existed in the language. Is there language support for these in the newer Java versions (I'm not up to date with newer features, since I won't be able to use them on Android anyway)? The reason for these getters/setters is as you said: a workaround for the language deficiencies. It's true for quite a few patterns, and it's not unique to Java; you get similar (in nat…

I think it's strange that people complain about the verbosity and boilerplate getters and setters in Java when this is entirely a non problem, provided your code is well designed. If your class has any setter function, you're doing OO wrong. Mutating an object should 1) only happen if you have a very good, inescapable reason; 2) never be exposed directly to code outside the class, including children. If your class mu…

I almost agree with you, I don't agree with the gatekeeping/nitpicking of saying "you're doing it wrong"

But I do agree that in most cases you don't need to call individual setters. And especially not automatically create one for every variable in your class

Re: My 20 year career is technical debt or deprecated

#547

Post by knorker »

Jorengarenar wrote: post #492
knorker wrote: post #485

Earlier quoted context omitted.

You should make friends with Steve Gibson ( https://www.grc.com/ ). He writes all his code is assembly. :-)

Don't worry, I personally know plenty of devs whose favourites are assembly, C, C++, Pascal, Perl... even BASIC, Fortran, COBOL or Forth! And surprisingly enough, among them, even the old farts aren't so old.

Bah, as someone who until recently had C++ as favorite language (now Rust), I'd say C++ doesn't belong on that list!

But so say probably all those people too, about "their" language. ;-)

Re: My 20 year career is technical debt or deprecated

#548

Post by lizmat »

cesarb wrote: post #505
senko wrote: post #495

Earlier quoted context omitted.

I believe so, after years of being vapourware and basically stopping Perl 5 development right when web as a platform started being important.

Perl 6 did get released, with that name, after years stuck in development (source: https://developers.slashdot.org/story/15/12/26/0354235/perl-... ). Only later was it rebranded.

In 2019 to be precise: https://raku.org

Re: My 20 year career is technical debt or deprecated

#549

Post by peteforde »

xiphias2 wrote: post #265
peteforde wrote: post #134

It's so weird that you'd even consider putting Rails in the same category as FoxPro, even as a theoretical. Rails is kicking ass. A huge number of people are coming back from bloated JS frameworks to realize that Rails just keeps getting better every year. Hotwire and similar technologies make the argument for SPAs look very questionable. And let's not forget where we are; over 75% of the raw gross value created by Y…

You don’t need to use a bloated JS framework. I think TypeScript is important because of how bad JS operators are defined (operator matrix is just plain stupid, throwing error would be a better option), but everything else is optional. Otherwise JS is good enough. On the other hand hotwire (moving HTML around) costs real latency and money to mobile users with data plans. Since when it’s better than just executing cod…

I fail to understand how shuttling JSON back and forth is superior to sending the HTML fragment(s) that have changed.

JSON needs to be parsed and in 99% of scenarios, this blocks the main thread.

Once the JSON has been converted to a data structure and passed around through your SPA's state logic and template rendering, what do you do? You convert it to HTML and render it.

No matter how you slice it, sending HTML fragments and updating the DOM is faster and lighter than sending JSON. My app is already displayed and responsive before your app has even started parsing.

The above doesn't even address the complexity and additional failure modes that you take on when you have to handle edge cases and errors, all of which is quite literally reimplementing functionality that the browser and HTTP already give you.

SPA supremacy is a group delusion mind virus. Thank goodness the pendulum is finally swinging back.

Re: My 20 year career is technical debt or deprecated

#550

Post by kqr »

luckman212 wrote: post #90
jcpst wrote: post #70

Earlier quoted context omitted.

Sqlite intends to keep their cathedral intact until 2050. https://sqlite.org/lts.html

SQLite is awesome. TIL that its database structure is robust enough to have been chosen as one of only 4 Recommended Storage Formats for long term data preservation[0]. > "Recommended storage formats are formats which, in the opinion of the preservationists at the Library of Congress, maximizes the chance of survival and continued accessibility of digital content. [0] https://www.sqlite.org/locrsf.html

Along with... xls.
Post reply on HN