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

521–530 of 585 posts

Re: My 20 year career is technical debt or deprecated

#521

Post by TRiG_Ireland »

revelio wrote: post #387
parthianshotgun wrote: post #365

Earlier quoted context omitted.

Steven Colbert once jokingly said, "Reality has a well known liberal bias". It should probably be the other way around, that liberals have a reality bias, but it doesn't quite land. Liberalism is based on what can be proven. Especially in science, starting with some preconceived reservations leads to inaccurate models. If you can't articulate it, all the worse. Even things like categorization and taxonomy can't accou…

Trying desperately to stay on technical topic here, I'd say the only places where this dichotomy comes up are in cases that are inherently ambiguous and subjective. If something is genuinely proven then everyone does actually accept it. Conservatives and liberals don't disagree on the energy of an electron or the color of the sky. Disagreement occurs over things that can't be proven: how valuable is spending time on…

> If something is genuinely proven then everyone does actually accept it.

This is demonstrably untrue. Vaccines. Evolution. Anthropogenic Global Warming.

Re: My 20 year career is technical debt or deprecated

#522

Post by josephg »

FpUser wrote: post #471
akavi wrote: post #443

Earlier quoted context omitted.

Objects are a useful idea. Object Orientation is a terrible, terrible idea. Functions + data (immutable when practical) is all you need for 90%+ of programming, and you should only reach for objects when necessary to manage some well-encapsulated but tricky state. Your default orientation should certainly not be towards objects.

>"Your default orientation should certainly not be towards objects." My default orientation should be what my experience tells me is the best for particular case.

You should trust your judgement. But good judgement comes from experience. Anyone who only has experience programming in one language, or one style, will have rubbish judgement.

Go learn Haskell, OCaml or Rust. Write some C for embedded platforms. Make a video game using your own hand spun ECS in C++. If, after all that, you come back and say "yeah lets use a class here", then I'll trust your judgement.

Re: My 20 year career is technical debt or deprecated

#523

Post by osigurdson »

The_Colonel wrote: post #373
osigurdson wrote: post #356

Earlier quoted context omitted.

>> bunch of code-as-XML for configuration Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).

It's a step back in a way. Code as XML had DTD with on the fly validation and autocomplete. JSON and YAML are still playing catch up in this area.

I have lots of biases against XML. For me it is nearly personified as Steve Balmer. However, it is rather funny to see people who hate XML yet love html (or even more absurd XAML). The autocomplete feature makes XML somehow not completely horrible as you can easily define a schema and get a kind of mini language with zero effort. Eventually the mind removes the tags and you are just left with the content. However, I see text formats that describe tree structures are all fundamentally the same. It is impossible for json, yaml to be waaaay better than XML as it is the exact same thing.

Re: My 20 year career is technical debt or deprecated

#524

Post by josephg »

jcranmer wrote: post #404
josephg wrote: post #306

Earlier quoted context omitted.

Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “…

> I want to link it to whoever insisted on adding a useless TextDecoder class in javascript that you have to instantiate, instead of just calling textDecode(…, “utf8”) using a global function like the rest of the standard library. I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial i…

> I for one would rather punch the person who proposes such a global function as the only mechanism for conversion, because charset conversion is a reasonable thing to do on chunked partial inputs

Fight me.

Javascript has a separate TextDecoderStream class if you want to support chunked, partial inputs. The TextDecoder class doesn't support streaming input at all. And it never will, thanks to the existence of TextDecoderStream.

TextDecoder only provides 1 method - TextDecoder.decode(). And the method is pure! So you could just make it a global method without any loss of functionality. The entire class has no mutable state whatsoever. Its just a container for some options, passed into the constructor. Those options could just have been passed straight to a global decode() method.

https://developer.mozilla.org/en-US/docs/Web/API/TextDecoder

This might be idiomatic C++, but its terrible javascript. I had a friend who worked on the Chrome team years ago. He said a lot of the browser engineers who design javascript APIs are C++ programmers who don't know javascript properly. So of course they port C++ ideas into javascript directly. They don't know any better. This is why javascript's standard library is an incoherent mess.

Re: My 20 year career is technical debt or deprecated

#525

Post by Izkata »

josephg wrote: post #507
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…

> 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 This always strikes me as any-benefit mentality thinking. I agree there is some small marginal benefit to this pattern, but the cost (in time, decreased readabili…

It was originally for libraries that were distributed as jar or class files without the original source, that crept into general "best practices". Also IntelliJ didn't even exist in the 90s when this started.

Re: My 20 year career is technical debt or deprecated

#526

Post by FpUser »

josephg wrote: post #522
FpUser wrote: post #471

Earlier quoted context omitted.

>"Your default orientation should certainly not be towards objects." My default orientation should be what my experience tells me is the best for particular case.

You should trust your judgement. But good judgement comes from experience. Anyone who only has experience programming in one language, or one style, will have rubbish judgement. Go learn Haskell, OCaml or Rust. Write some C for embedded platforms. Make a video game using your own hand spun ECS in C++. If, after all that, you come back and say "yeah lets use a class here", then I'll trust your judgement.

I am paid for designing and implementing products. Language for me is a screwdriver. Some convenient some not that much. I have programmed in many languages. I am familiar with the concepts but not going to learn OCaml or Haskel as there is zero ROI in it for me.

>"If, after all that, you come back and say "yeah lets use a class here", then I'll trust your judgement."

Look at it this way. I care what my customers say about my products because this is how I make my money for decades already. You - trusting my judgement - I do not give a flying fuck. Sorry for being direct.

Re: My 20 year career is technical debt or deprecated

#527

Post by richardw »

mongol wrote: post #163
richardw wrote: post #67

One company I worked at had heavy SQL Server stored procs. I was pretty dismissive initially ("don't put business logic in the database layer!") but grew to understand that really those were the gold. The first versions were written in 1997 and by the time I arrived that code was bulletproof. There were about 4 UI technologies over 20+ years (VB, ASP, Forms + asp.net), but the procs were the same shape with thousands…

Yeah, when I started in this field 20+ years ago, the wisdom I learned was that it was bad practise to tie yourself to the DB like that. But just like you I can see the value in doing it. SQL may be one of the most futureproof languages there are.

Exactly. Code you learned a decade ago is absolutely useful today.

When I started I outsourced SQL to the DBA’s or an ORM. Not since that team! It’s been a semi-secret weapon for me because most people ignore it.

Re: My 20 year career is technical debt or deprecated

#528

Post by josephg »

Izkata wrote: post #525
josephg wrote: post #507

Earlier quoted context omitted.

> 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 This always strikes me as any-benefit mentality thinking. I agree there is some small marginal benefit to this pattern, but the cost (in time, decreased readabili…

It was originally for libraries that were distributed as jar or class files without the original source, that crept into general "best practices". Also IntelliJ didn't even exist in the 90s when this started.

It exist now. And even before intellij and eclipse had automated refactoring tools, it was like a 5 minute refactor. Just change your public field to be private, add getters and setters then play whack-a-mole mechanically fixing all the compiler errors that showed up.

I can see the argument for putting them in APIs exposed in jar or class files without the source. But the tasteless trend of adding getters and setters everywhere just looks to me like cargo culting. Its sheep programmers leading other sheep. You can tell its cargo culting because if you questioned anyone about the practice they would always ultimately justify their actions by saying "oh, I just do it because everyone else does it".

I believe its the responsibility of every engineer to decide for themselves what they think beautiful code should look like. You get some pointless arguments, sure, but the alternative is always a mess.

Re: My 20 year career is technical debt or deprecated

#529

Post by Izkata »

josephg wrote: post #528
Izkata wrote: post #525

Earlier quoted context omitted.

It was originally for libraries that were distributed as jar or class files without the original source, that crept into general "best practices". Also IntelliJ didn't even exist in the 90s when this started.

It exist now. And even before intellij and eclipse had automated refactoring tools, it was like a 5 minute refactor. Just change your public field to be private, add getters and setters then play whack-a-mole mechanically fixing all the compiler errors that showed up. I can see the argument for putting them in APIs exposed in jar or class files without the source. But the tasteless trend of adding getters and setters…

I agree with the cargo-culting, but the person I originally replied to seemed to think there was never any point, and that's what I was replying to - there was a reason it started.

Re: My 20 year career is technical debt or deprecated

#530

Post by jen20 »

piokoch wrote: post #428
jen20 wrote: post #277

Earlier quoted context omitted.

I assure you code as XML has not disappeared from enterprise Java.

It has not disappeared from enterprise and this has nothing to do with Java. XML is still very good as a document format, with powerful validation capabilities (XSD) and powerful language to do transformation of documents (XSLT), searching documents (XPath). It is still used for a reason. In addition there are standard ways of encrypting/signing XML documents.

Those aren’t the parts that are used though - it’s the Spring XML as the replacement for the “new” keyword that is more likely to be found than XSLT or XSD.
Post reply on HN