pull down to refresh

101 sats \ 12 replies \ @south_korea_ln 11 Mar \ on: SN release: what you see is what you get (wysiwyg) editor meta

> Also, big shout to @optimism who has been helping us put the engineering back in software engineering.

In what sense?

Also, good job!

write
compose
22 sats \ 11 replies \ @k00b OP 11 Mar

Generally, he's been pushing for more rigor in dev processes and alerting us to how accessible rigor is now.

reply
224 sats \ 10 replies \ @south_korea_ln 11 Mar

Haha, maybe I should ask him a crash course on this too. We lack a lot of rigor in academic coding...

reply
224 sats \ 8 replies \ @SimpleStacker 11 Mar

I've kind of gone the other way. I used to spend a lot more time making my research code elegant, extensible, and modular.

But I realized that I rarely benefitted from it, since the requirements of different projects are often so different.

So I'm much more comfortable slapping together code that just gets the job done now. For my research work, at least.

reply
249 sats \ 7 replies \ @optimism 12 Mar

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.)
reply
1 sat \ 6 replies \ @south_korea_ln 12 Mar

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 12 Mar

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 12 Mar
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 12 Mar
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
view all 3 replies
1 sat \ 0 replies \ @k00b OP 11 Mar

If you detail your frustrations or questions in a post, you might be so lucky.

reply