pull down to refresh

249 sats \ 7 replies \ @optimism 14h \ parent \ on: SN release: what you see is what you get (wysiwyg) editor meta

I think that it only makes sense in production code. I basically have 4 levels of rigidity:

  1. poc - just yolo it
  2. private tooling - never goes out of alpha stage. I do review and test it, but I'm wary of spending too much time on it.
  3. FOSS software of minor consequence. Full blown vibe design-code-review on this. A gazillion rounds of hybrid AI+meat review. Still faster (2x or so) and much higher precision (10x or so)
  4. FOSS software of importance. I only use AI in the review portion of this, or suggest a code solution (but it'll never get merged) for codebases I do not fully own (for example, I needed to patch a pinned OpenSSL dependency on an important library, and the bot found me a narrower patch than just porting over the upstream commit verbatim, which I then verified and executed manually.)
write
compose
1 sat \ 6 replies \ @south_korea_ln 12h

I guess I rarely venture outside of 1 and 2 with my codes. I do have a FOSS code that I maintain and build on regularly, and collaborators are free to use it, with the huge caveat that I am not responsible for any errors in the code. They are also free to modify it, but they rarely do, as most are allergic to Fortran. And it's very much spaghetti code that I've only recently started to refactor using Cursor.

reply
1 sat \ 5 replies \ @optimism 11h

Yes. So don't waste too much time. For your refactoring, especially in fortran, I'd go the way of 3, simply because you don't want to introduce sloppy architecture.

I posted a bit about this process yesterday, in #1452429.

If your software were something like openssl or the linux kernel or in general something considered best in class and has gotten a couple 100k installs, you want to be extremely careful. This is what 4 is for.

reply
1 sat \ 4 replies \ @adlai 10h
Yes. So don't waste too much time. For your refactoring, especially in fortran, I'd go the way of 3, simply because you don't want to introduce sloppy architecture.

@south_korea_ln how's the weather, in any other language?

reply
1 sat \ 3 replies \ @south_korea_ln 10h
program weather_report
  implicit none


  character(len=*), parameter :: msg = "날씨가 좋아요."

  call say_weather(msg)

contains

  subroutine say_weather(text)
    implicit none
    character(len=*), intent(in) :: text
    write(*,'(A)') trim(text)
  end subroutine say_weather

end program weather_report

Edit: I used to use this syntax, though:

PROGRAM WEATHER_REPORT

      CHARACTER*40 MSG
      INTEGER I

      MSG = '날씨가 좋아요.'

      I = 1
 10   IF (I .GT. 1) GOTO 20
      CALL SAYWEATHER(MSG)
      I = I + 1
      GOTO 10

 20   STOP
      END


      SUBROUTINE SAYWEATHER(TEXT)
      CHARACTER*40 TEXT

 30   PRINT *, TEXT
      GOTO 40

 40   RETURN
      END
reply
1 sat \ 2 replies \ @adlai 10h

no offense intended, are you trying to get muted?

riffing off "a rose by any other name" seemed nicer than "why the fuck are you coping with that old crap"

reply
1 sat \ 1 reply \ @south_korea_ln 9h

Nope, not trying to get muted. I just played along with your jab at Fortran.

Seems like you take things literally, so let me do the same.

why the fuck are you coping with that old crap

Because it works, is faster than many other codes, and it is just not worth it to rewrite legacy code.

reply
1 sat \ 0 replies \ @adlai 9h
same.
why the fuck are you coping with that old crap
Because it works, is faster than many other codes, and it is just not worth it to rewrite legacy code.

my least favorite "just a chill dude" advice is "plan to throw one away; you will, anyway"

hearing that from a professional C++ barf cope artist, about a Common Lisp hairball, is honestly insulting.

please believe me, I honestly have a lot of respect for people who maintain codebases older than their children.

reply