lysdexic

joined 2 years ago
MODERATOR OF
[–] lysdexic@programming.dev 0 points 2 years ago (3 children)

Probably a little of both, but I really don’t think there are very many practical applications for current AI technology.

I don't think that's true at all.

A couple of days ago I read a post about someone using ChatGPT to generate commit messages from the diff. That's pretty cool.

Chatbots are also surprisingly helpful. Today's technology is already good enough to put together working expert systems. I'd love to have something like a chatbot that was fed something like all the papers from one or more academic journals related to a specialized field, and be able to ask it open-ended questions.

I think that nowadays the limit for actually useful AI is the imagination of those who work on today's cutting edge AI. It would be cool to hear more about those.

[–] lysdexic@programming.dev 1 points 2 years ago

it’s a reflection of the huge effort providing actually useful ai posts

Nonsense. All it takes is pasting a URL, or write a question similar to the one I posted.

No one is asking for a doctoral dissertation. All it takes is someone posting something like "hey look everyone I think this use of AI is pretty cool."

[–] lysdexic@programming.dev 14 points 2 years ago* (last edited 2 years ago)

From the article:

(...) but recently, another type of criticism seems to be on the rise.

The code that I suggest is too verbose. It involves too much typing.

This reads like a one-sentence strawman. Describing code as "too verbose" is really not about the risk of carpal tunnel syndrome. It's about readability and cognitive load.

The blogger seems to almost get the point when he writes the following:

In short, the purpose of source code is to communicate the workings of a piece of software to the next programmer who comes along. This could easily include your future self.

The purpose of source code is to communicate (...) to the next programmer who comes along.

If you make the mistake of going the "enterprise quality java code" meme approach, you're making the next programmer's life needlessly harder.

The blogger then tries to make his case with verbose code, and makes the following statement:

Which alternative is better? The short version is eight lines of code, including the curly brackets. The longer version is 78 lines of code. That's ten times as much.

I prefer the longer version. While it takes longer to type, it comes with several benefits. (...)

This is yet another strawman. The longer version is awful code, not because it's longer but because it's needlessly jam-packed of boilerplate code. Ignorign basic things like interfaces and contracts, It's been proven already that bugs in code are directly proportional to the number of lines of code, and thus the code the author prefers is likely to pack ten times more bugs.

The shorter code in this case would not be the 78-loc mess that the author picked as the thing he prefers. The shorter code in this case would be something like onboarding the project onto Project Lombok to handle all-args constructors, property methods, and even throw a builder in for free. This requires onboarding Lombok to the project, and add two annotations to the short example. Two lines of code, done.

After the blogger fails to make his case, he doubles down on the typing non-sequitur:

Perhaps you're now convinced that typing speed may not be the bottleneck (...)

This is a blog post that fails to justify a click. It's in the territory of "not even wrong".

[–] lysdexic@programming.dev 2 points 2 years ago

I would expect more negativity than average because ‘actually useful’ is relative and frankly, I cant be bothered to make my case.

Perhaps it's just me, but the way I interpret the "actually useful" is that the goal is to showcase practical uses of some AI implementation showcasing how it's used to solve real world problems.

This is fundamentally different than all the "solution in search for a problem" announcements which ride the AI buzzword, which boil down to handwaving over their practical relevance.

[–] lysdexic@programming.dev 1 points 2 years ago

Kotlin is IMO easier and less error prone

I'm no Kotlin expert, but I think Kotlin has a far more extensive core language and requires a heavier cognitive load to get up and running than Java.

It might have better developer experience and be less error-prone, but that comes at a price of admission that newbies have to pay.

[–] lysdexic@programming.dev 1 points 2 years ago

There’s Tauri.

...and now your newbie has to onboard onto not only Rust (?!) but also HTML, CSS, and JavaScript to render "Hello World".

[–] lysdexic@programming.dev 2 points 2 years ago

Surely you got a bonus and a raise out of it right? Right??

The only reward I got from it was recognition from my team members, which was already more than what I was expecting to get.

My manager was praised for the higher team velocity and improvements in the team's burndown chart. The hallmark of having done good work is seeing others trying to take credit for it.

[–] lysdexic@programming.dev 15 points 2 years ago (2 children)

The optimization I'm the most proud about was when I worked on a legacy project whose end-to-end builds took around 1 hour. After spending some time working on its architecture, project layout and build system, I managed to get the full end-to-end builds to take 10 minutes, and incremental builds to be almost instant.

What makes me the most proud about this project is that the technical debt plaguing the legacy project was directly and indirectly the reason why half a dozen of my team members burned out and quit the company. After that point my remaining team members started to be far less stressed and team velocity skyrocketed, just for the fact that the thought of iterating over a bugfix and posting a pull request didn't cost at least one hour, and sometimes two or three.

[–] lysdexic@programming.dev 3 points 2 years ago

I wish there was a linter that stopped my colleagues from adding in a half-gigabyte of Apache Spark artifacts to go with a single line of code, which makes the product impossible to deploy to customers;

It sounds like this would be simple to catch during code reviews, or in the very least with a regression test running after the packaging stage.

or to implement another fucking O(n^2) algorithm that flies through the test suite and craps out in production;

It sounds like the job for a performance test.

or our placement students from trying to get ChatGPT shit through code review.

Aren't code reviews catching this?

I also fucking hate checkstyle, or any of its friends like Google’s spotless; sometimes you want to format your code so that the underlying thinking is more obvious, perhaps to highlight how some parts are different and make things that are not as you would expect stand out, but no.

I'm afraid that's not supposed to be handled at the code formatting level. That's supposed to be handled by extracting code to a method or a dedicated class, and cover with unit tests to illustrate how it's expected to work. If you're trying to handle that with non-standard code formatting then I'm afraid you're writing bad code.

[–] lysdexic@programming.dev 1 points 2 years ago (1 children)

The Rust community is a very diverse group of people with many different opinions. It is not a universal truth that the Rust community believes Rust to be an awful first language.

You don't need to take my word for it. Google the topic and go through all the discussions. Even the ones in Rust's own forum get mixed responses, and that community is by its very nature very partial towards Rust.

Also, framing the discussion around newbies learning Rust as a first language is a strawman. The question is not whether if someone without any prior experience in programming can or cannot make and effort and write code in Rust. The question is which language to learn.

There are many programming languages to pick and choose from, and some are renowned to be very beginner friendly. Rust is not one of them.

If you want to make a case for Rust, it's up to you to prove that Rust is a better language to take first steps than any other programming language around. In my personal opinion, it is simply not possible to claim that Rust is better for this particular usecase than quite a sizable set of programming languages, including but not limited to Python. If you want to claim Rust is better suited then you need to make a case for it, and that is a challenging thing to pull off.

[–] lysdexic@programming.dev 1 points 2 years ago (2 children)

You missed the point

What point do you think I missed?

[–] lysdexic@programming.dev -2 points 2 years ago* (last edited 2 years ago) (3 children)

You’re not making the strong case that you think you are. Quite the opposite. The ease of “shooting yourself in the foot” is precisely what makes it so difficult to learn. Segmentation faults and random memory corruption make it incredibly hard to get started with programming.

That's not the case, though. Some C and C++ compilers are already resilient and flexible enough to not get C and C++ to blow up in your face when you're doing unmentionable things to memory access. Some memory safety issues are only noticeable when running profilers and memory safety tools.

Keep in mind you are talking about someone taking their first steps in writing software. They are struggling to get stuff to work, and throwing curve balls at them is not going to help them get on their feet.

Also, I did not advocated for C or C++ as better options. My point is that Rust is an awful suggestion as a first language, which even the Rust community states. It also speaks volumes to Rust's unsuitability as a beginner programming language if the best attempt to refute that fact is to try to come up with worst alternatives that in the end aren't even worse at all.

Rust’s constraints are very clear and concise in comparison (...)

Irrelevant. The point is that Rust enforces constraints that other programming languages don't. If anyone is taking their first steps, not having to deal with them leads to a far more productive and enjoyable experience. It's absurd to talk about memory-safety and performance when the target audience doesn't even understand what memory is.

 

LinkedIn woke up today and decided to dish out the pain.

 

One of my main gripes regarding git is that it just generates diffs per line regardless of context or document format. This can be frustrating as it often leads to diffs that cover the end of a function declaration that was not touched and leaves out the end of a function that was just added.

Git supports diff options such as patience and histogram but , even though they mitigate some problems, they are still fallible.

So does anyone know if there is any way to get git to do context- or document format-sensitive diffs?

view more: ‹ prev next ›