Live data from Hacker News

Tips for stable and portable software

begriffs.com

41–50 of 63 posts

Re: Tips for stable and portable software

#41

Earlier quoted context omitted.

> If you're in a web startup, software won't last 3 years, the next team will systematically rewrite. I have an old man rant about that actually... that rewrite is typically unnecessary if you actually use discipline when developing and learn how to read code. I once took on a CakePHP 2 app and another developer asked me how in the world I got into, and understood, the framework so quickly. My secret? I read the Cake…

> that rewrite is typically unnecessary if you actually use discipline when developing and learn how to read code "But developers that can exercise discipline and know how to read (and modify) code instead of rewriting cost so much money..." is what you'll typically hear in response to this. It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times…

> It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times than it is to have more expensive, more disciplined, more experienced developers write something and maintain it.

I can't believe this. I've seen the sheer difference in speed and maintainability a single solid web developer can deliver in a framework they are familiar with versus teams of more Jr developers who spin their wheels for weeks. Rewriting when you don't even understand the starting point is always a waste of money.

> It's also harder to keep the more experience developers because most developers I work with start looking for another job when their project goes into maintenance.

This certainly resonates though. I've been that developer more than once.

Re: Tips for stable and portable software

#42
post #37

I'm currently "betting" on Go for making a back-end (just a REST API + sqlite database) that will last a decade; I'm betting on the tooling to stay backwards compatible or with minimal changes in the codebase; I'm betting on the readability of my own code for the next decade, and I'm betting on the language + tools to continue to be developed whilst sticking to their original goals. Generics is going to be fun.

I can't tell if you want generics or not? I've been thinking about the topic for a while and sort of think Go doesn't need em. It's less a technical reason but more a cultural reason. The language shipped without them as a feature. So why deprecate that feature and make lite-version of Java/C#.

A decent chunk of new Go developers are former Java developers. (I'm not being disparaging here, I came over to Go from Java!) I think the idea of "accept interfaces, return structs" doesn't sink in very well and isn't as readily apparent as it could be.

When I have a function that takes a struct, and I need it to take a different struct for the same argument due to whatever, that to me screams "make an interface", but I hadn't been programming Java very long before my team started using Go - I've now been writing Go professionally longer than I have Java.

Re: Tips for stable and portable software

#43
post #2

> Tips for stable and portable software I think a more accurate title would be "Tips for stable and portable C programs"

The author lists a number of languages considered stable, C being one of them because of widespread support and portability. Java isn't portable for example because it depends on the JVM (and I know GraalVM is a thing but will you still be able to use it in ten years?).

Show me a JavaScript developer that cares deeply about POSIX or the operating system they are running on.

And what about Windows? It is still used on 80% on all computers? So why is POSIX essential?

Re: Tips for stable and portable software

#44

Earlier quoted context omitted.

-pedantic only enables warnings, it cannot change the meaning of code; not even on newer compilers.

You are right, I mis-remembered what the flag did, sorry. I've seen projects with -pedantics -Werror, which are particularly annoying (-Werror in general to be honest, I understand why people might want it for CI of course).

I like using -Wall -Wextra -Werror for code under my control, but I would disable that flag if distributed as a library to others.

Re: Tips for stable and portable software

#45
post #36

Earlier quoted context omitted.

The same reason why my default stack is still Java/Kotlin with Spring and Hibernate. A stable environment, stable runtime that is guaranteed to not change too much and has a culture of backwards compatibility.

How are you liking Java with all the versions that are dropping. Are you still on 8? Correto? Or are you keeping up? and do you see the value in the features that are dropping.

Java is moving a lot faster now with the new 6 month release cadence but you don't need to follow every release. Sticking to LTS releases is fine for projects that require longevity.

Some projects are still using 8 and will be until their EOL date. New projects start on the latest LTS release (11).

Re: Tips for stable and portable software

#46

Really weird that he recommends Motif. Motif is not comparable to Web/Gtk/Qt since it has only the most primitive widgets, and no 3D support. I would propose doing a web-app if you really care so much about compatibility. Web also allows for more custom widgets.

Is Motif actually available on modern Linux systems? And is there a Windows port as well?

I find it difficult to believe that Motif is actually that portable.

Web apps are only as portable as the browser features they use, and the browsers available for the platform. A primarily backend-rendered app, with minimal Javascript is much more portable than the average SPA app.

Re: Tips for stable and portable software

#47

Earlier quoted context omitted.

> that rewrite is typically unnecessary if you actually use discipline when developing and learn how to read code "But developers that can exercise discipline and know how to read (and modify) code instead of rewriting cost so much money..." is what you'll typically hear in response to this. It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times…

> It's cheaper (and often faster) to have cheaper, less disciplined, less experienced developers rewrite something multiple times than it is to have more expensive, more disciplined, more experienced developers write something and maintain it. I can't believe this. I've seen the sheer difference in speed and maintainability a single solid web developer can deliver in a framework they are familiar with versus teams of…

> I can't believe this. I've seen the sheer difference in speed and maintainability a single solid web developer can deliver in a framework they are familiar with versus teams of more Jr developers who spin their wheels for weeks. Rewriting when you don't even understand the starting point is always a waste of money.

I agree completely.

It can be quite shocking just how much damage a poor developer can do to small to medium companies. I know of 1 company that's holding on for dear life right now because they lost their biggest client due to a very poor developer they had employed. I told them 6 months before this all happened to get rid of him, but they didn't. And Corona is just making it that much harder for them to find new work.

Re: Tips for stable and portable software

#48

Earlier quoted context omitted.

> I'm betting on the tooling to stay backwards compatible or with minimal changes in the codebase This is actually why I'm pretty bullish on things like RoR, Laravel, et al. The sheer speed at which they go to a new version that breaks BC is actively making the web less secure. I've lost count of how many times I've found a new client with this software that's been working for years but suddenly broke, only to realiz…

> This is actually why I'm pretty bullish on things like RoR, Laravel, et al. Do you mean bearish? I think you do as I was confused for about half of your comment before I realised

Sorry, you're correct. I meant bearish.

That's what I get for posting pre-coffee :(

Re: Tips for stable and portable software

#49

Really weird that he recommends Motif. Motif is not comparable to Web/Gtk/Qt since it has only the most primitive widgets, and no 3D support. I would propose doing a web-app if you really care so much about compatibility. Web also allows for more custom widgets.

Is Motif actually available on modern Linux systems? And is there a Windows port as well? I find it difficult to believe that Motif is actually that portable. Web apps are only as portable as the browser features they use, and the browsers available for the platform. A primarily backend-rendered app, with minimal Javascript is much more portable than the average SPA app.

> Is Motif actually available on modern Linux systems?

https://www.archlinux.org/packages/community/x86_64/openmoti... lists as being updated 2020-01-05, and https://sourceforge.net/p/cdesktopenv/wiki/SupportedPlatform... claims that CDE supports a rather lot of platforms (which implies motif), although I'll grant that most of those probably haven't been tested in a while.

Re: Tips for stable and portable software

#50
post #2

> Tips for stable and portable software I think a more accurate title would be "Tips for stable and portable C programs"

The author lists a number of languages considered stable, C being one of them because of widespread support and portability. Java isn't portable for example because it depends on the JVM (and I know GraalVM is a thing but will you still be able to use it in ten years?).

> Java isn't portable for example because it depends on the JVM

By that logic C isn't portable because it relies on libc.

Post reply on HN