I haven't tried ChatGPT for coding yet but I have used it to study human languages (I've been studying Japanese for a little while) and it's so easy to get it to spew complete nonsense with perfect aplomb that it makes me super wary of using it for any "serious" things. In particular anything you're not super familiar with where you can't easily evaluate if the output is correct or not.
The other day I was struggling to parse a Japanese sentence, a particular grammatical construction made no sense to me. I wrote the sentence in ChatGPT, asked it to break it down for me, and it came up with a plausible-sounding explanation. Problem was, I couldn't find any hit on google when I searched for the thing it was talking about. So I asked ChatGPT to give me more details, tell me what I could search for, and it would insist that its explanation was correct and then gaslight me by telling me that the reason I couldn't find anything on Google was because it was a niche subject not usually taught in grammar books.
After some more searching around and double-checking it turns out that I had misread a kanji and the sentence I typed into ChatGPT was complete gibberish as a result. ChatGPT's explanation, while sounding very plausible, was complete fabrication.
The idea that some inexperienced people are shipping software using this tool is insane to me.
> The idea that some inexperienced people are shipping software using this tool is insane to me.
I really think you're trying to compare apples and oranges, in multiple ways. For one, we can test the software by running it, which is a pretty different problem from asking language questions, with a much slower ability to verify correctness (based on what you describe and what I imagine).
I'm not saying your experience is invalid. In my own adventures, the equivalent of what you did was my writing some incomplete bash in an existing script, wandered off to another part of the code. I then came back to that incomplete snippet, and though it was some unfamiliar syntax someone else had written (vim even highlighted it like it was special!). Naturally I went and asked ChatGPT what that snippet did, and wasted 15 minutes trying to corroborate it before checking the git history or something and realizing my own error.
As long as the tests are not also written by ChatGPT...
Many critical security issues require a deep understanding or the code or some intense fuzzing to discover, it's not enough to ask ChatGPT "write me X" then superficially glance at the output to validate that it looks correct. That's the part that worries me. Completely broken code will be caught immediately, but subtly broken code may linger for a long time and make it to production.
And from my limited experience with ChatGPT, it seems very good at making up broken things that look superficially correct.
Just wondering, are you trying it with GPT-3.5 or GPT-4? Better to use GPT-4 API version since the web version’s quality was controversial. When you feel quality is subpar you should try to use the best one first.
The thing that annoys me is that you can ask it to do something specific but it does what it wants.
For example I had a massive sql query that was loads of statements unioned together, I said “for each statement remove this filter and add this filter” and it would go “certainly, here are the first four, I have used an example table name feel free to change it” then I’d say “can you do it for all the statements, not just the first four” and it would say “of course here you go” and just give me the first four but also makes them useless by changing the table name!
I’ve got great hopes that one day I can get it to help me shape the code in a way that the jetbrains ide’s can’t today - for those I have to choose from a set of available operations - I want to talk to it and get it to change the code in a set of operations that I choose!
Perhaps, but I wouldn't mind if the models just answered "I'm sorry but I don't have an answer to your question at the time". In fact I think that would be a great answer that would increase the amount of trust I have in ChatGPT.
Instead the model decides to make stuff up and pretend that it knows. That's vastly worse.
It reminds me of the early days of DuckDuckGo, when if you searched for something obscure with no matches online it would still fuzzy match some garbage like a binary blob in a Chinese PDF while Google helpfully would just tell you that it couldn't find anything.
> Instead the model decides to make stuff up and pretend that it knows. That's vastly worse.
Does the model know it doesn’t know though? Does “know” even make sense as a concept here? I don’t know if it can really introspect like that, but of course it would be so much better if it could can have some sort of confidence score with each answer.
All of these reasons boil down to "if it ain't broke" and "that's what we're used to".
Switching VCS for a project of this size is always complicated and OpenBSD devs are famously "old school" and conservative with their software choices.
I used to use CVS before switching to SVN and later DCVS like Mercurial and Git. The claim that "it is unlikely that any alternative versioning system would improve the developer's productivity or quality" is absolutely laughable IMO.
This is especially true nowadays where CVS support in modern tooling, if it even exists, is usually legacy and poorly maintained.
> All of these reasons boil down to "if it ain't broke" and "that's what we're used to".
"Works for us". Which is a pretty good argument.
> The claim that "it is unlikely that any alternative versioning system would improve the developer's productivity or quality" is absolutely laughable IMO.
Why is it laughable exactly? I mean for me I can't use CVS due to the lack of atomic directory checkins, but if they don't need them or they have already a system in place which may even better tie with their development/release style than any generic VCS could, why bother?
> This is especially true nowadays where CVS support in modern tooling, if it even exists, is usually legacy and poorly maintained.
A service may provision an account with a provided ssh public key, so that you never log in with a password, even once.
It's sort of a chicken-egg problem though, presumably you do have a password somewhere along the line, such as in a portal where you created your account and uploaded your public key.
I'd say there are more valuable things you can do to improve security than solving the problem of "having to ssh in with a password one time to upload a key"
Maybe. Not having a password on the server eliminates all the risks associated with weak or leaked passwords. And then you can configure SSH to reject password logins altogether. It's not an insignificant benefit.
I'd say there are more valuable things you can do to improve security than solving the problem of "having to ssh in with a password one time to upload a key, then updating the config to reject password logins".
SSH password login is secure. Keys are preferred since you can't have asdf1234 as a key, but if you as the initial person to set up the server are the only one allowed password login and use a decent password, you're fine
...Key-distribution is to encryption systems as cache-invalidation is to computer science. Both of which are subforms of the ur-problem of signal-propagation which itself is stemmed from the physical principle of causality.
Only way through it is to shut up and do it, sadly.
The implementation details of doing it are often either A) have physical possesion of computer, and do initial insecure setup within a "secure realm" you control, or B) redefine your "secure realm" to include the hardware being in someone else's possession, and do what they tell you and pray they are trustworthy.
If you notice that some of your confidential info made it into next generations of the model, you'll be able to sue them for big $$$ for breach of contract. That's a pretty good incentive for them not to play stupid games with that.
I started with tcsh because it was the standard on BSD at the time, then I moved to zsh and never looked back. Using shells with non-POSIX syntax is nice in theory but the pros don't outweight the massive con of not working out of the box on most systems, at least for my usage.
The idea of using structured data instead of raw bytes always seemed like a brilliant idea, so I commend Microsoft for pushing the concept with their PowerShell, but I'm a un*x user and all the operating system and tooling is built around dumb `char[]` pipes so unfortunately that's a lost cause as far as I'm concerned.
I suppose a big player like Red Hat or Ubuntu could push for a complete migration of the kernel + userland towards structured pipes, but I'm not sure why they would. From anecdotal evidence it seems to me that shell power-usage is not as popular now than it was in the past, most junior devs I encounter seem to barely use pipes at all, let alone write complex scripts. They rely on VSCode to launch the build commands and they do everything else through GUI. When they need to do something on the CLI they usually just copy/paste from stackoverflow. Why bother overhauling the shell if it's becoming a legacy tool?
It saddens me a bit but I also get it. It's not like shell scripts and Makefiles and autotools stuff are a pleasure to work with... Maybe it's for the best.
> most junior devs I encounter seem to barely use pipes at all
Is popularity among junior developers the right metric? Aren't most junior developers permanently junior? I see the movers and shakers of the industry writing shell scripts all the time, probably still too often relative to, e.g. Python scripts.
I found this article in the citations of the Wikipedia article for Final Fantasy VII and found it extremely interesting, containing many interesting bits of translation lore from both the technical and linguistic sides.
> There's something more constricting about there being one function to bootstrap everything than there is about one file.
As someone who basically started coding with C I feel the other way around, unsurprisingly. Even in scripting languages when I write something non trivial I tend to encapsulate everything in functions and then have a `main()` call at the bottom of the file. I think it's one of the things python got right with the `if __name__ == "__main__":` idiom that lets you import any script in a REPL to test individual methods for instance.
(Although the actual syntax of `if __name__ == "__main__":` is IMO utter trash and it amuses me that a language so obsessed with getting rid of symbols and looking like pseudocode decided that such cumbersome, obtuse and ugly looking boilerplate was just fine.)
> (Although the actual syntax of `if __name__ == "__main__":` is IMO utter trash and it amuses me that a language so obsessed with getting rid of symbols and looking like pseudocode decided that such cumbersome, obtuse and ugly looking boilerplate was just fine.)
This reminds me of when I tried learning Ruby. The tutorial I read started by talking about how elegant and beautiful Ruby could be, and how easy it is to read and understand Ruby at first glance, even if you’re new to it. Then they explained that the toString method in Ruby is called `.to_s()` and that lambda arguments were surrounded by pipe characters and I was like “wat”.
> it amuses me that a language so obsessed with getting rid of symbols and looking like pseudocode decided that such cumbersome, obtuse and ugly looking boilerplate was just fine.
100 times this! I have always wondered about that.
Python is quick and dirty and always has been. The language designers have regularly papered over design flaws using hacks and magic syntax.
Which is acceptable. Python is a valuable tool I use on a daily basis. But I find it annoying when Python programmers are snooty about "Pythonic" code.
The thesis I've heard (and agree with) is that Python is a good everything language. For specialization there is always a better tool (although maybe more complex to get started).
It's perhaps not as life-changing as some of the sibling replies but one thing that has really amazed me over the past few decades is how much lighting has progressed.
When I was a kid in the 90's I already enjoyed electricity and electronics and I would play with those low power incandescent lightbulbs powered by 9V batteries. They would generate a lot of heat and very little light, to the point that it wasn't easy to tell if it was on when the sun was bright.
With a modern LED and the same setup you could generate enough light to blind yourself.
I like to point this out in relation to Star Trek. In TNG, they had tablet computers, replicators, teleportation, voice command, all these things that we consider future magic or current awesome technology. And then an away team goes down to the surface and pulls out a flashlight using an incandescent bulb that can barely be seen.
LEDs are genuinely revolutionary in a way everyone just kind of overlooks.
Ten years or so ago I was working on a video chip that had an upscaler feature. While prototyping and simulating it, we first started by applying a mathematically-correct (i.e. information preserving) FIR filter to do the upscale. Then we compared the result with other solutions and found that ours looked worse. We asked our colleagues to blind-test it and they all picked third-party-scaled images over ours.
At first we assumed that we must have had a bug somewhere because the Fourrier transform told us that our approach was optimal, but after more testing everything matched the expected output. Yet it looked worse.
So we started reverse-engineering the other solutions and, long story short, what they did better is that they added some form of edge-enhancement to the upscaling. Information-theory-wise it actually degraded the image, but subjectively the sharper outlines were just so much nicer to look at and looked correct-er. You felt like you could more easily tell the details even though, again, in a mathematical sense you actually lost information that way.
I don't think it makes a lot of sense to reduce human vision to edge detection (we can still make sense of a blurry image like this one after all: https://static0.makeuseofimages.com/wordpress/wp-content/upl... ) but it's clear to me from empirical evidence that edge-detection is a core aspect of how we parse visual stimuli.
As such I'm a bit confused as to why the author seems to see this as a binary proposition. That being said, I could just be misunderstanding completely the point the author is trying to make.
I don't think it's just subjective in this case. The theoretical signal processing approach assumes that the signal is band-limited to frequencies less than two pixels wide, and it's not. There are lots of sharp edges that have higher frequency components than that.
Another way of looking it, more along the lines that you're talking about, is that it depends on your error model. The traditional way of measuring error is RMS pointwise in pixels. Doing some sort of interpolation on pixels gives a pretty good result for that. However, another way to look at it is that it may be better to have a positional error, i.e. a particular color or intensity level is in the wrong spot, than to have an intensity/color error, i.e. you have a pixel that has an intensity/color that's not present in the source signal.
This same basic issue was the basis of a big divide in font rendering for many years, where the Mac would render fonts with the exact geometry of the letters, but then anti-aliased, while Windows would use font hinting to make the shape snap to the pixel grid. Personally I thought that the Windows approach was a lot easier to read on a screen, but the Mac approach had the advantage that the geometry of the text would be exactly the same in print as it was on the screen, back when print was something that was important, especially for Mac users.
Sounds like using the wrong metric, the upscaled image should be compared against the original full resolution one, not the downscaled one. Obviously you can't know what the full resolution one looks like when actually upscaling (vs testing), but you can make an educated guess.
You can remove the guesswork. You can start with a high resolution (or even raster export of a vector image for an extreme example), downsample it (various methods and downsampling factors for completeness), then attempt to upscale it.
The difference between the data in the image, and the information? If for instance you upscaled text so large that it became blurry and unrecognizable, you lost information.
Our cortext is all about interpreting what we see. Almost before our brain proper has the data, nerves have begun extracting information (edges etc). Probably because it was the difference between hitting and missing the animal with the spear. Or seeing or missing the tiger in the grass.
Precisely! I also find it interesting how, from an information theory standpoint, audio processing and image processing are effectively the same thing (audio resampling is fundamentally 1D image scaling for instance) but because humans process sounds very differently from images we end up doing things pretty differently.
For instance when we want to subjectively make images more attractive we tend increase contrast and sharpness, whereas for sound we tend to compress it, effectively reducing "audio contrast".
The old habit of reaching to “increase contrast”[0] as a means of making an image more attractive exists in large part because 1) the dynamic range of modern display media is so tiny compared to the dynamic range of camera sensors and our eyes[1], and 2) the images most people typically work with are often recorded in that same tiny dynamic range.
If you work with raw photography, you will find that, as with audio, the dynamic range is substantially wider than the comfortable range of the available media: your job is, in fact, to compress that range into the tiny display space while strategically attenuating and accentuating various components—just like with raw audio, much more goes into it than merely compression, but fundamentally the approaches are much alike.
[0] Which actually does much more than that—the process is far from simply making the high values higher and low values lower.
[1] Though “dynamic range” is much less of a useful concept when applied to eyes—as with sound, we perceive light in temporal context.
Surely if you're upscaling pixel art you're loosing information when you create gradients between pixels. It doesn't seem to me that your metric of information loss was ideal.
Conservation is not just about preserving info, it's also about not adding information that's not here. If you upscale without those gradients (effectively sharpening to the max with nearest neighbor extrapolation) you introduce high frequencies that could not exist in the original data. You've created new information out of nowhere.
But of course you're correct that in this case it may be the desirable outcome. I still think that this idea of creating information using algorithms in order to get a subjectively more pleasant result is really one of the biggest issues of our time. Not a day passes where I don't see AI-colorized pictures, AI-extrapolated video footage, AI-cleaned family portraits, AI-improved smartphone footage etc...
It's both amazing and a bit scary, because in a certain way we rewrite history when we do this, and since the information is not present in the original it's very difficult to ascertain how close we truly are to reality. We're creating a parallel reality, one Instagram filter at a time. Maybe that's the true metaverse.
> in a certain way we rewrite history when we do this
History is sort of inherently rewritten. Memories are (very!) imperfect and even without realizing it we interpret events through our individual biases. Maybe the more precise concern is the increasing _willful_ departure from reality, but we do that naturally too, overlooking parts of reality that would be intolerable if they were always in our face.
Quite, no new information so no “loss” but not the information that needs to be there.
It’s putting an 8oz coffee brew in a 20oz cup & giving it to the customer as a large saying they had no coffee loss. While true, it’s not the same as delivering a 20oz coffee.
The upscaled image stores more information than the original image, so it must be possible to keep all the information while still doing edge enhancement!
Stores more data, but the same information, and if there is any interpolation then some of the data is modified, meaning that you lose a little data. In fact even without interpolation I think you change the data.
If you imagine a hard edge that aligns with a pixel [] boundary then you imagine upscaling in various ways, I think it's QED. You change data about the sharpness of the edge.
[] I use an Android phone, with Google's keyboard it genuinely rendered "pixel" with a capital letter. I've never written about Google's device of that name. Silly Google.
Well consider nearest neighbor upscaling. Since we are upscaling, every pixel in the source image will determine one our more pixels in the result image. Consider one of the source pixels that turns into multiple result pixels. If you manipulate one of those while leaving the other(s) intact you can still recover the source image (assuming you know which pixels are still good), meaning no data was lost.
Ah, right, anything that's a function purely of what's in the image - no randomness, no external context/'knowledge' to interpret it semantically, is as you say 'encoding the same information in different ways'?
If it can be computed (deterministically) from the image alone, then it was already there.
It's like playing a familiar song on an old cassette tape on a modern system. The user will likely be tempted to crank up the treble, trying to recover content that isn't there. In the image-scaling example, the HF content wasn't there to begin with -- since you upsampled it, it couldn't have been! -- but there's a strong psychological expectation for it to be there.
With images, it's a bit easier to put the high frequencies back in via judicious use of edge enhancement, perhaps because you have two dimensions to work with rather than one dimension in the audio case.
This is unfortunately still the norm in the FPGA world, which I think is a poor decision in the long term for Intel/Xilinx. I wanted to seriously get into FPGA dev a decade or so ago, I learned to write Verilog and everything but the tooling made me give up, it was too painful to deal with all the quirks and limitations of the free tools.
You sign up on their website and click ok on the long eula nobody reads and then click download. So yea, there are probably restrictions, but they don't have a paywall in front of them. This isn't legal advice at all.
The other day I was struggling to parse a Japanese sentence, a particular grammatical construction made no sense to me. I wrote the sentence in ChatGPT, asked it to break it down for me, and it came up with a plausible-sounding explanation. Problem was, I couldn't find any hit on google when I searched for the thing it was talking about. So I asked ChatGPT to give me more details, tell me what I could search for, and it would insist that its explanation was correct and then gaslight me by telling me that the reason I couldn't find anything on Google was because it was a niche subject not usually taught in grammar books.
After some more searching around and double-checking it turns out that I had misread a kanji and the sentence I typed into ChatGPT was complete gibberish as a result. ChatGPT's explanation, while sounding very plausible, was complete fabrication.
The idea that some inexperienced people are shipping software using this tool is insane to me.