snowe

snowe, 1 month ago

My response to the article is that you’re sacrificing gains in language because some people use outdated tools. Code has more context than what is just written. Many times you can’t see things in the code unless you dig in, for example responses from a database or key value store, or literally any external api. Type inference in languages that have bad IDE support leads to a bad experience, hence the author’s views on ocaml. But in a language like Kotlin it’s absolutely wonderful. If needed you can provide context, but otherwise the types are always there, you can view them easily if you’re using a decent IDE, and type inference makes the code much more readable in the long run. I would say that a majority of the time, you do not care about the types in any application. You care about the data flow, so having a type system that protects you from mismatched types is much more important that requiring types to be specified.

snowe, 1 month ago

Does type inference provide a practical benefit to you beyond saving you some keystrokes?

it’s more readable! like, that’s literally the whole point. It’s more readable and you don’t have to care about a type unless you want or need to.

What tools do you use for code review? Do you do them in GitHub/gitlab/Bitbucket or are you pulling every code review directly into your IDE? How frequently do you do code reviews?

I use GitHub and Intellij. I do code reviews daily, I’m one of two staff software engineers on my team. I rarely ever need to know the type, and if I do Github is perfect for 90% of use cases, and for the other 10% I literally click the PR button in intellij and open up the pull request that way. It’s dead simple.

snowe, 1 month ago

Forking is a foolish idea. The core principle of computer-science is that we need to live with legacy, not abandon it.

what a crazy thing to say. The core principle of computer-science is to continue moving forward with tech, and to leave behind the stuff that doesn’t work. You don’t see people still using fortran by choice, you see them living with it because they’re completely unable to move off of it. If you’re able to abandon bad tech then the proper decision is to do so. OP keeps linking Joel, but Joel doesn’t say to not rewrite stuff, he says to not rewrite stuff for large scale commercial applications that currently work. C clearly isn’t working for a lot of memory safe applications. The logic doesn’t apply there. It also clearly doesn’t apply when you can write stuff in a memory safe language alongside existing C code without rewriting any C code at all.

And there’s no need. Modern C compilers already have the ability to be memory-safe, we just need to make minor – and compatible – changes to turn it on. Instead of a hard-fork that abandons legacy system, this would be a soft-fork that enables memory-safety for new systems.

this has nothing to do with the compiler, this has to do with writing ‘better’ code, which has proved impossible over and over again. The problem is the programmers and that’s never going to change. Using a language that doesn’t need this knowledge is the better choice 100% of the time.

C devs have been claiming ‘the language can do this, we just need to implement it’ for decades now. At this point it’s literally easier to slowly port to a better language than it is to try and ‘fix’ C/C++.

snowe, 1 month ago

I can’t speak for C, as I don’t follow it that much, but for C++, this is just not fair. It has been proven repeatedly that it can be done better, and much better. Each iteration has made so many things simpler, more productive, and also safer. Now, there are two problems with what I just said:

That comment was not talking about programming languages, it was talking about human’s inability to write perfect code. Humans are unable to solve problems correctly 100% of the time. So if the language doesn’t do it for them then it will not happen. See Java for a great example of this. Java has Null Pointer Exceptions absolutely everywhere. So a bunch of different groups created annotations that would give you warnings, and even fail to compile if something was mismatched or a null check was missed. But if you miss a single @NotNull annotation anywhere in the code, then suddenly you can get null errors again. It’s not enforced by the type system and as a result humans can forget. Kotlin came along and ‘solved it’ at the type level, where types are nullable or non-nullable. But, hilariously enough, you can still get NPEs in Kotlin because it’s commonly used to interop with Java.

My point is that C/C++ can’t solve this at a fundamental level, the same way Kotlin and Java cannot solve this. Programmers are the problem, so you have to have a system that was built from the ground up to solve the problem. That’s what we are getting in modern day languages. You can’t just tack the system on after the fact, unless it completely removes any need for the programmer to do literally anything, because the programmer is the problem.

Surely not for everything. Of course I see great value if I can stop depending on OpenSSL, and move to a better library written in a better language. Seriously looking forward for the day when I see dynamic libraries written in Rust in my package manager. But I’d like to see what’s the plan for moving a large stack of C and C++ code, like a Linux distribution, to some “better language”. I work everyday on such a stack (e.g. KDE Neon in my case, but applicable to any other typical distro with KDE or GNOME), and deploy to customers on such a stack (on Linux embedded like Yocto). Will the D-Bus daemon be written in Rust? Perhaps. Systemd? Maybe. NetworkManager, Udisks, etc.? Who knows. All the plethora of C and C++ applications that we use everyday? Doubtful.

I’m not talking about whole scale rewrites. I’m talking about what Linux is already doing with writing new code in Rust, or small portions of performance critical code in a memory safe language. I’m not talking about like what Fish Shell did and rewrote the whole codebase in one go, because that’s not realistic. But slowly converting an entire codebase over? That’s incredibly realistic. I’ve done so with several 250k+ line Java codebases, converting them to Kotlin. When languages are built to be easy to move to (Rust, Kotlin, etc), then migrating to them slowly over time where it matters is easily attainable.

snowe, 1 month ago

Rewriting projects from scratch by definition represent big step backwards because you’re wasting resources to deliver barely working projects that have a fraction of the features that the legacy production code already delivered and reached a stable state.

Joel’s point was about commercial products not programming languages. I’m not the one misunderstanding here. When people talk about using Rust, it’s not talking about rewriting every single thing ever written in C/C++. It’s about leaving C/C++ behind and moving on to something that doesn’t have the issues of the past. This is not about large scale commercial rewrites. It’s about C’s inability to deal with these problems.

You are just showing the world you failed to read the article.

sure thing bud.

Also, it’s telling that you opt to frame the problem as "a project is written in C instead of <insert pet language> instead of actually secure and harden existing projects.

I didn’t say that and you know it. Also it’s quite telling (ooh, I can say the same things you can) that you think “better language” means “pet language”. Actually laughable.

snowe, 1 month ago

It’s also just a huge fallacy. He’s saying that people just choose to not write memory safe code, not that writing memory safe code in C/C++ is almost impossible. Just look at NASA’s manual for writing safe C++ code. It’s insanity. No one except them can write code that’s safe and they’ve stripped out half the language to do so. No matter how hard you try, you’re going to let memory bugs through with C/C++, while Rust and other memory safe languages have all but nullified a lot of that.

snowe, 1 month ago (edited 1 month ago)

en.wikipedia.org/…/The_Power_of_10%3A_Rules_for_D…

and their 40 page coding standard document. ntrs.nasa.gov/api/citations/…/20080039927.pdfntrs.nasa.gov/citations/20080039927

and their software safety handbook. standards.nasa.gov/standard/nasa/nasa-gb-871913

all 389 pages of it standards.nasa.gov/sites/…/nasa-gb-871913.pdf

snowe, 1 month ago

Also, writing memory safe code honestly isn’t that hard. It just requires a different approach to problem solving, that just like any other design pattern, once you learn and get used to it, is easy.

the CVE list would disagree with you.

snowe, 1 month ago

it does if the other ones have edible seeds, seeds without arsenic, or fewer seeds… your analogy makes no sense.

snowe, 1 month ago

Mercedes isn’t competing against cheap cars locally, so it has no incentive to block their import.

snowe, 1 month ago

I am of no help here, but your post made me think of this. youtu.be/tbazGVrbN-g

snowe, 1 month ago

You ask them to add a license, you don’t suggest a license.

snowe, 1 month ago

You can write cross platform mobile (and desktop and even browser) apps with Kotlin.

snowe, 1 month ago

It doesn’t sound like you want a static site generator. You want a Squarespace alternative. One option I use is Ghost. You can host it yourself for free. But it’s not a static site. Static site means static. That means no backend, no forms, none of that. You won’t get a CMS, you won’t get drag and drop components. That’s not what static site generators do.

snowe, 2 months ago

yeah as @Ategon said, that’s quite strange, but I’m not sure we’re in control of that. Would need to be raised as an issue. lemmy.world has also customized their install quite a bit so it could also be on their side.

snowe, 2 months ago

that’s so weird because I got an email inviting me to participate and I haven’t ever been considered a ‘prolific poster’. I’m only at 60k and 12 years. I had no clue I was invited until I looked in my spam folder.

snowe, 2 months ago

I’ve been saying this for years. My site only has a few lines of javascript. the rest is pure html and css, and it’s very simple. tylerthrailkill.com

snowe, 2 months ago

Hm. what browser are you on? It is showing sun for me on light mode. https://programming.dev/pictrs/image/51eeae04-0e2b-4515-8e25-a0ad4ae7153e.png

snowe, 2 months ago

It shouldn’t be like that. on my computer it shows the sun when it’s in light mode, moon in dark mode. https://programming.dev/pictrs/image/a61e84c4-7278-4410-a422-780530f4fbf2.png

snowe, 2 months ago

that post is about toggle buttons, not switches. e.g. a play pause button, when pressed, does it show play, or does it show pause?

snowe, 2 months ago

I’ve wondered what this problem was for years but never cared to figure it out, because it always resolved after the first button press (just refresh the page and it all works properly). turns out it is something wrong with my use of local storage to save your theme state. if you don’t have the key in local storage then it does what you mentioned. I just need to switch this to prefers-color-scheme anyway.

snowe, 2 months ago

still, people are clearly confused by the button. I’m just gonna make it an animation and prefers-color-scheme since that’s so widely supported now.

snowe, 3 months ago

Because no one ever uses those. Literally > and | are the only ones I’ve ever seen in over a decade and you will never need to worry about the differences between the two.

XML as a configuration language is terrible. Yaml gets the point across in an easily readable way, which is exactly the point. Same for JSON except JSON you can’t even use comments (you need json5 or one of the numerous other alternatives to get those).

snowe, 3 months ago

Oh dang, I’ve wanted that forever. Thank you!

snowe, 3 months ago

Awesome. Installing now