HackerTrans
TopNewTrendsCommentsPastAskShowJobs

synthc

no profile record

comments

synthc
·vorige maand·discuss
I gave it a weird and convoluted code snippet, and asked an LLM to step through the execution and trace the value of the variables at each step.

It was completely correct and I realized LLM are capable of generalizing beyond their training sets
synthc
·4 maanden geleden·discuss
`uv agent` and `bun agent` in 3....2.....1....
synthc
·4 maanden geleden·discuss
Very hit or miss.

Stack: go, python Team size: 8 Experience, mixed.

I'm using a code review agent which sometimes catches a critical big humans miss, so that is very useful.

Using it to get to know a code base is also very useful. A question like 'which functions touch this table' or 'describe the flow of this API endpoint' are usually answered correctly. This is a huge time saver when I need to work on a code base i'm less familiar with.

For coding, agents are fine for simple straightforward tasks, but I find the tools are very myopic: they prefer very local changes (adding new helper functions all over the place, even when such helpers already exist)

For harder problems I find agents get stuck in loops, and coming up with the right prompts and guardrails can be slower than just writing the code.

I also hates how slow and unpredictable the agents can be. At times it feels like gambling. Will the agents actually fix my tests, or fuck up the code base? Who knows, let's check in 5 minutes.

IMO the worst thing is that juniors can now come up with large change sets, that seem good at a glance but then turn out to be fundamentally flawed, and it takes tons of time to review
synthc
·4 jaar geleden·discuss
I've worked with Clojure for years using the REPL driven approach and found I needed restarts quite often, for example when adding updating dependencies or other changes to the project file.

REPL driven development is great, but sometime you want to make sure that you are not using some function that was only defined in the REPL session but not in the source code. Also the REPL session sometime gets in a bad state when printing big outputs, blocking forever with some concurrency stuff or other mistakes.
synthc
·4 jaar geleden·discuss
No namespaces loaded is not a very good benchmark IMO, a real project will have lots of them.

I've worked on a large project with many namespaces and dependencies and it took about 20 seconds.
synthc
·4 jaar geleden·discuss
When you mess up the repl session somehow, for example by starting a http server on a port but not storing the server object. You now have blocked a port, and restarting the server does not work. Or if you run something like (future (while true ...))

There is some wierdness when redefining protocols and multimethods where a good 'ol restart is the easiest way to set things right.

Try working in an ecosystem with fast compile and startup and you will see why it is an advantage
synthc
·4 jaar geleden·discuss
This is just not true at all.

Everyone can join the Clojurians slack, it is a very welcoming place, also to newcomers, in my experience.

Everyone can create issues and patches, getting them accepted may take a long time, but the core team does a great job of maintaining high quality and not breaking things.
synthc
·4 jaar geleden·discuss
I'm very familiar with the live editing aspect of Clojure, and I like it a lot actually.

What I am saying is that Clojure's long startup time is still annoying if you want to restart, for example if you trashed your repl session or want to start with a clean slate.

If Clojure would start fast enough it could also be used for CLI scripts and we would not need Babashka at all.

All in all, I think Clojure is a great language, but the slow startup time is still a disadvantage.
synthc
·4 jaar geleden·discuss
I've used all combinations lein,deps,figwheel,shadow-cljs,cider and cursive, but haven't been able to reproduce the same frictionless setup I had then, something always breaks when switching between clj and cljs files.
synthc
·4 jaar geleden·discuss
I feel your pain regarding ClojureScript.

A few years back there was a 3 month window where I had everything (lein,fighweel, emacs) configured just right, and I could reliably start a Clojure REPL, a Clojure Script REPL connected to a browser window, and switch between them from emacs.

It was really productive, I could work on the backend parts, frontend parts, and effortly switch between REPLS, but then there were some updates and I never got it working without friction again.
synthc
·4 jaar geleden·discuss
I also worked this way, I've had REPL sessions that ran for months, but IMO this is a workaround rather than a real solution. It's a good workaround, but fast startup would be a game changer.

If Clojure would start fast enough, projects like Babashka would not be needed.
synthc
·4 jaar geleden·discuss
REPL driven development is great, but there are still tons of situations where you want a full recompile and restart. Slow compile and start time really slow down development.

Recently I was porting a small application from Clojure to Rust, and 'cargo watch -x run' was faster than 'clojure.tools.namespace.repl/refresh' and is more reliable.
synthc
·4 jaar geleden·discuss
Yeah it is too bad Incanter stalled, it could have been an great alternative to Python's data science stack (pandas/numpy/matplotlib) if it had gotten traction at the right time.

It lacks some polish and has some wierd conventions relative to modern Clojure, but I still use it occasionally.
synthc
·4 jaar geleden·discuss
I would not say it is dead at all.

There are still Clojure jobs and new companies using Clojure.

It is a niche language, and I think it will stay a niche language, but that is fine.