Hacker Newsnew | past | comments | ask | show | jobs | submit | otabdeveloper4's commentslogin

This one is pretty easy!

Just write your business requirements in a clear, unambiguous and exhaustive manner using a formal specification language.

Bam, no coding required.


damn if only this language could be made to work with numbers we would really have something. Let's ask an LLM about it

> They're measuring development speed through lines of code.

Yeah, this is the biggest facepalm.

Didn't we grow out of this idiocy 40 years ago? This shit again? Really?


Whenever actual studies are made about LLM coding they always show that LLM coding is a net loss in quality and delivery speed.

(They are good as coder psychotherapy tho.)


One of the "actual studies" was pretty much grabbing developers off the street and telling them to "use AI to make things go fast".

And to no-one's surprise there was no increase in velocity.

I'd really like to see a study using people of similar skill level where one group doesn't use AI and never has and the other have been working with AI tooling for a year or more.


> you just need AI certification and over five years experience in AI coding stacks to make use of this

The trillions of dollars of capitalization wasn't based off a promise of "a new IDE that lets you write code slightly faster once you get over the learning curve".


Well, things are changing so fast those studies are going to be out of date. And I have no doubt some people are experiencing a net loss while others are not. We need to pry apart why some people are having success with it and others aren't, and build on top of what's working.

Sounds a lot like "software engineering".

Wasn't AI supposed to free us from all that and let us fire all those useless coders?


Just use a custom PATH and run in a chroot jail.

CLI sandboxing is a solved problem compared to whatever MCP is.


LLMs are good for documenting specific things.

E.g., "find where the method X is called and what arguments are passed".

That can be useful for refactoring or debugging.

Coding is the worst way to use an LLM though.


They're good enough already.

The moat is only

a) post-training magic for the elusive UX "vibes"

b) stickiness of the Claude UI's.

The first part will be eventually (give it a couple years) solved by a LoRA marketplace.

The second is not relevant because existing UI's are very sticky already and Claude won't be able to overcome decades of inertia anyways.


That and the price of hardware

> Digital is endlessly flexible

Not really. Analog electronic instruments are based on non-linear feedbacks loops. Those are pretty much impossible to emulate digitally without emulating actual electric circuits and current flow.

(Yes, I know, irrelevant to the vinyl discussion.)


I used to think that, and indeed a computer can run any equations you want. However with analogue you're getting a bunch of interesting-sounding equations without having to think of them and write them down, and that's the "analogue sound." Analogue circuitry isn't a perfect math processor the way digital is, only an approximation, and the deviations from perfection are useful.

Especially if you get into synths. A digital sine wave oscillator is doing sin(time*frequency)*gain. An analogue one is designed to produce a close to perfect sine wave at a certain set point, but you make it able to be varied around that set point by replacing some of the components with adjustable ones in somewhat ad-hoc ways, and see what it sounds like. The frequency may be set by a 3-stage RC circuit, you replace all the Rs with vactrols and see what happens, now the impedance changes as well as the frequency and it might affect other parts of the circuit. You may one-point calibrate it to 1 volt per octave but it won't be linear.


I'm convinced that at least 90% of "analog sound" can be simulated by taking the ideal block diagram and replacing every link with a parametric EQ->waveshaper->parametric EQ chain. Configuring those added components correctly is left as an exercise for the reader.

Jim Lill's video on guitar amp tone is an interesting demonstration. Hear how close he gets to the original with an even simpler combination of EQ and distortion:

https://www.youtube.com/watch?v=wcBEOcPtlYk


Probably. We can calculate or at least measure and reproduce the effect of every analogue component, and simulate exactly what the circuit does. But we don't do that.

Coincidentally my statement comes from the position of someone who has been building and designing analog synths for years and teaching exactly that on the university level.

The analog part of a synth can be meaningful and sometimes it is. But very often it is really not or can be adequately (or more then adequately) emulated digitally.

As a noise musician I am also aware that a lot of the interesting behavior of some circuits only comes to light under extreme conditions. It is a long standing pet peeve of mine that equipment tests always only test the gear in vanilla conditions. But quite frankly vanilla conditions are exactly what 99.9% of the musicians will use the gear with


> But quite frankly vanilla conditions are exactly what 99.9% of the musicians will use the gear with

Any filter resonance or guitar distortion/overdrive is not a "vanilla condition", so you're absolutely wrong.

In fact, the extreme conditions is precisely the reason why normies even listen to music. Nobody would care for electric guitar if it wasn't overdriven.


I also happen to play electrical guitar distorted half my life. Distortion isn't as complicated to emulate as you make it out to be. In fact the hardest part about doing digital distortion is having the analog frontend and the ADC be good enough, since you will add hefty (digital) gains to the signals.

Hoe do I know? I am working on a digital distortion pedal right now. If done right software emulation of guitar amplification chains is pretty good nowadays. Many touring musicians use Neural DSP Quad Cortex and Co nowadays.

I happen to also like the simplicity and robustness of just a stupid analog amp, but those aren't as special as the gearsnobs make them out to be.


I happen to both teach electronics on a university level and DSP program, so I will add a [citation needed] to your statement. Yes, there are analog circuits whose edge case percularities have not yet been adequately represented in digital circuits. But much of that is nor whar the layperson would even use and beyond any limits of perception.

All analogue oscillators and filters are based on nonlinear feedback loops.

Those nonlinearities can't really be modeled mathematically.

We very carefully tune these things to a narrow range of stable parameters so that they sound more "digital", but really it's the unstable parameter ranges that make music interesting.


Yes of course they can be modeled mathematically. Why couldn't they be? The analog circuits I build I simulate ahead of time using LTSpice. You can even output wav files from LTSpice and listen to them. Simulation takes ages since LTSpice isn't all that well optimized for modern Computers, but it works pretty well and matches what I see in analog circuits that I have produced. Sure there are problems where the Spice model for specific parts is too simple, but very often it turns out that these are not important for the characteristic sound of the circuit.

To me a statement as the one you made just showcases how little people know about the matter. Many just repeat talking points they have heard elsewhere.

Don't get me wrong. It is hard to e.g. accurately model a Wasp Voltage Controlled Lowpass Filter so it sounds as good as the real thing. But it is not even remotely impossible. There are much, much harder problems in electrical engineering that have been solved decades ago.


Note you're replying to a guy who never said anything at all about being "faster".

P.S. Software developers aren't being paid to be "fast". In fact, being "fast" is called "technical debt" and you're usually punished for it as a software developer.


All my self-hosted inference has temperature zero and no randomness.

It is absolutely workable, current inference engines are just lazy and dumb.

(I use a Zobrist hash to track and prune loops.)


> Will your lifetimes work also be a mystery to future generations and will they shrug and say "all this computer code must be for religious sacrifice, we can see no other purposes for it"?

I doubt any computer code will survive for 1000 years.


really? I feel absolutely assured that every ugly temporary code fix I put in place, will persist for eternity..

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: