Bluntly, yes. And so is every other reply to you that says "no this isn't naive", or "there's no reason this project shouldn't have finished". All that means is that you've not seen a truly "enterprise" codebase that may be bringing in tons of business value, but whose internals are a true human centipede of bad practices and organic tendrils of doing things the wrong way.

Currently there. On one hand: lot of old code which looks horrible (the "just put comments there in case we need it later" pattern is everywhere). Hidden scripts and ETL tasks on forgotten servers, "API" (or more often files sent to some FTP) used by one or two clients but it's been working for more than a decade so no changing that. On the other: it feels like doing archeology, learning why things are how they are (politics, priority changes over the years). And when you finally ship something helping the business with an easier to use UI you know the effort was not for nothing.

Unless I guess you train an AI on a given topic, like a few languages or a database or something. But given ChatGPT's apparent vulnerability to just making shit up, you'll have to call me skeptical if this has any real use.

How many times have you asked a co-worker about something and they gave you a convincing answer that was totally wrong? Did it make you stop asking co-workers for help?

Conversely, there are people who I will go to for topics that they are not the SME in, maybe their teammate even is, but I trust their ability to do quality research and intelligently interpret that research for case specific nuances. Like I'll go to the networking guy to talk about some DB thing because the DB guys are morons and live and die by junk SEO sites but the networking guy can think analytically and find the source of truth documentation and provide excerpts from it.

These chat bots "know" a shit ton and a half of stuff in that they are connected to the largest collection of knowledge known to man, the Internet. But "knowing" and "understanding" are two different things. The various search engines also "know" a ton about where to find things online, that doesn't mean they know shit about those things. And as we're seeing here: without the context to know that when someone wants an IP scanner, they want something good, that won't give their computer malware, that'll be reasonably priced or even open source, or even what platform, it just gives an answer based on a search.

You could just search for ip scanning software and gotten all the information BingGPT shared with the author of the piece.

And like, if you wanted to be charitable, you could say "well the author should've given more information about what they wanted" but again, that's not different from an existing search engine and more crucially: the AI didn't ask questions. Didn't ask for platform, how much they wanted to spend, if they preferred open source, or even something more general like what they were trying to accomplish. Nada. Just did a search, and reported results.

Y'all keep throwing out these gotcha statements that just make the technology you're trying to tell me is great seem more and more useless.

How can you even attempt to call something artificial intelligence if it doesn't even know the year it is!?

> Indeed, and that is a big part of misunderstanding. GPT-4 is, on many topics, closer to understanding than knowing (note that neither is a subset of the other). The conceptual patterns are there, even if sometimes are easy to accidentally overpower by the prompt, or by the sequence of tokens already emitted.

I don't think it's either understanding or knowing. Someone who knows something isn't going to spontaneously forget it because someone asked them a question incorrectly.

That specific unreliable coworker who doesn’t properly qualify that they aren’t completely certain … I believe for most people, yes.

We tend not to trust bullshitters.

Never actually. My coworkers have never told me something with confidence that they just made up. If they don't know an answer, they may provide hints and directions, but it will be clear they don't know.

i mean, in many circumstances, we absolutely stop asking them...

when i ask a trustworthy human a question, they will absolutely tell me if it is out their depths. they understand their own limits on around the subject and say so. and if they understand a little, they’ll help point towards people who would be a better authority on the subject.

that’s basic level human connection stuff.

if someone confidently gives you the wrong answer, refuses to know their own limits, and repeatedly leads you astray you don’t trust them after this do you?

One usually stops asking the bullshitter, yes.

F/k/a Putting a thing on the internet for randos to identify and explain. As long as it cites the LLM cites its sources, general questions in the form of "what is this" or "what's going on here" while you point to a page or an image or in a general direction are not well suited for search engines.

Not as accurate, but faster.

For some people - I am reluctant to say "for some use cases" - that's very appealing.

Like hell, if that's the standard, I'll be ChatGPT. You won't need an outrageous graphics card to ask me a question and I'll get you an answer right away. It'll almost certainly be the wrong answer, and is just an ass-pulled guess, but if that's all you want, I'll setup a chat website for myself and start taking queries today. Then investors can give me 10 billion dollars.

Problem: I want an AWS CLI command line that requests a whole bunch of wildcard certificates from AWS Certificate Manager (ACM) for a TLD.

Ostensible solution: the AWS official docs have a small snippet to achieve this, BUT -- the snippet on the official page is inadvisable as it leads to a browser cert warning.

So I (skeptically) asked ChatGPT for a command line to achieve what I was trying to do.

Try 1: got basically the snippet from the AWS official docs (but with the inadvisable flag set to the _Correct_ value, strangely)

Prompt 2: please give me more best practice options

Try 2: get back a bunch of new CLI options and their meanings. 3 are useful. 1 is hallucinated. 1 is deprecated.

Prompt 3: keep going with more options

Try 3: 2 more useful new options, 2 more options I chose not to use

As a skeptic, the overall experience was much more efficient that googling around or even reading a manpage. I put it all on the fact that context is maintained between questions, so you don't have to repeat yourself when asking for clarifications.

This might be a big part of why GP's case works. The model (GPT-4) most likely understands the concept of documentation being deprecated, so the more often v1 docs say it, the stronger a semantic link between current and obsolete docs, and the more likely it is for ChatGPT to give you answer based on non-deprecated docs.

Yes! Note that I had to use my domain knowledge to sift through the options and eliminate the garbage, but the experience was just _faster_ than repeated searches and digging through ad-laden garbage sites.

Also, not super relevant, but in e.g. combat situations one is often better off running now in any direction rather than pondering which direction is absolutely optimal for running from the lion. You'll know soon enough whether it was the right direction. There's probably a metaphor somewhere in there.

If you “have to double check everything”, what’s the point? Skip the AI and do the check you were going to do anyway.

Almost anything related to software development. Any answer I get online, whether from Wikipedia or a Github search or a Stack Overflow question or anywhere else, will require careful study and adaptation before I can use it. There will inevitably be things about any given solution that don't apply to whatever I'm doing, or that will be out-and-out wrong. But does that mean I'd be better off without doing a search at all? Of course not.

Same with AI. It can point me in the right direction and save me a lot of trouble, but it can't (yet) do my job for me.

When it gets 10x better -- and I'm sure it will -- then that last part can be expected to change. Which is awesome.

Meanwhile, Stack Overflow and Wikipedia and Github aren't going to get 10x better, ever. Not without cross-pollinating with AI.

I had this really annoying requirement to get multiple incompatible status codes, and output them in a consolidated human legible way.

So pretend I am using MSSQL, and I have 3 status code tables.

The status code integers are all slightly different. NEW is always 1, but "Completed" could be 5, 7 or 21 depending on table.

The actual "text" is an integer that can be linked to a Text table via the ID and Language name. But, due to the nuances being slightly different, each version can have a different ID. I can't just use DISTINCT on the text ids.

This is even more true when slight differences like "Complete" and "Completed" exist.

So I need to use UNION, to 'combine' multiple unrelated status code tables.

Then I need to get the language text, and SELECT DISTINCT (or something similar) per language.

Then that needs to be outputted as a drop down for the user.

Then, I have to use that as a other, separate input for another SQL query.

To say "using fast, slightly inaccurate GPT code" was faster than doing it by hand would be an understatement.

It gave me about 15 iterations, where about 6 sort of worked. Then I figures it out myself from there.

>> For some people - I am reluctant to say "for some use cases" - that's very appealing.

You're preaching to the choir.

However, do keep in mind that even authoritative sources found during your own research may be inaccurate. And for some questions, which answer is "right" or "wrong" may not be black and white.

I mean, sure. But again: that's just my point restated. What is this doing that a standard search engine does not?

Like, I put shit in my phone's calendar and set reminders so that I don't to think about it anymore. That is a cognitive load (remembering my dentist appointment) that I have now offloaded to technology. And that's useful as all hell, which is why my phone's calendar is full to the tits of everything one would put in a calendar. Now I don't need to think about it. I get messages from my phone when events are coming up, and I get a literal calendar on my screen when I want it, showing me all these things with perfect accuracy.

What is BingGPT in this scenario offloading? It's just a search engine but slower. It doesn't understand what good software is, so it can't make value based judgements on which to recommend. It doesn't know what reliable sources are, and can't evaluate for them, so every bit of information you get back must be treated with a grain of salt. It (probably) doesn't even remotely conceive of why you are asking it a thing or what a good answer to that query would look like because it doesn't know you, it just knows a massive, incomprehensible amount of averages about a ton of things that might be what you want.

And like, that's fine, search engines have had these limitations for my entire life. That's why I'm saying, I don't understand why this is better. It's the same thing as Bing, but slower, and in a chat box.

And again, it is quicker than clicking multiple links and can generalize / contextualize what it finds, mapping it to the answer you're looking for.

Have you tried asking one of these tools to write some simple scripts for you? It works decently, actually.

If you didn't already know how to program, this could save you a TON of time, even if it doesn't work perfectly on the first try.

Nice thing is, if it doesn't work perfectly on the first try, you can describe the problem (or paste the whole output, errors included), and get back a fixed version that's likely to work this time around.

> Vue uses a templating language closer to default HTML than to JSX, which makes it much easier to write conditionals and loops in template files

Bold of you to come to HN with the breathless hyperbolic marketing fluff that may work on Twitter...

[1] https://www.npmjs.com/package/ts-node

https://github.com/esbuild-kit/tsx

I gave tsx a test and found it has a 3x slower boot than my favorite one, tsm[0] (and this is using the native binary at "./node_modules/bin/tsx").

Unfortunately, tsm has much lower download numbers compared to tsx, so I can already see me jumping ship to it due to traction.

I usually install tsm locally with "--save-dev" and use "node -r tsm --enable-source-maps <file>.ts" to run what I want. Here on a M1 Pro 32GB the difference between both is 0.17s for tsx and 0.06s for tsm.

I urge anyone that haven't tried yet to give tsm a chance. It works great with PM2 if you create a file like "server.pm2.js" and just add at the top of it "require('tsm')" followed by "require('server.ts')".

[0] https://www.npmjs.com/package/tsm

Yes better than: 'Error: success' or 'keyboard not found: press F1 to continue'

> ts-node: Unknown file extension: ts.

Someone will reply for a technical reason about this (mentioning .mts or package.json settings or whatever) but that doesn't change the fact that a program whose only job is to run ts files should know what a ts file is. GitHub issue: https://github.com/TypeStrong/ts-node/issues/1967

tsx or @digitak/esrun both work out of the box.

And introducing new extensions like .mjs or .cjs is the smoldering dead raccoon responsible for half of the smell.

The painful move from IPv4 to IPv6 suggests that this is unlikely. More likely is an overlay over IP, TCP, or even HTTPS.

GNUnet can function as an overlay and an _underlay_ simultaneously, quoting from the dissertation:

> GNUnet is an overlay network, as it is initially supposed to primarily operate over the existing Internet network. However, GNUnet does not assume that this is always the case. For example, GNUnet can also operate directly over WLAN or Bluetooth to create an ad-hoc wireless mesh network, and with the GNUnet “PT/VPN” subsystems we can run TCP/IP over GNUnet. So in this configuration, GNUnet would be an underlay network, a bit like MPLS or B.A.T.M.A.N. [NAL07]. In reality, we in fact expect to see both at the same time: some peers will run over the existing Internet, while others may connect to GNUnet on Layer 2.

Lock-in? Once you have a few gigs up on Dropbox, it's a bit of a challenge transferring it elsewhere.

The few times I tried to use Drive, it was considerably more hassle to work with (and slow), iCloud was right out because it's Apple-platforms only, and my experiences with OneNote's sync issues makes me wary of trying OneDrive. Haven't looked at Box since I was under the impression it was aimed at businesses/enterprise more than individuals.

That has been the only cloud storage provider good enough (but not as good as) Dropbox to wean me away from DB. I've been using it for a couple of months now.

Edit: which is not to say that I'm not welcoming the new instructions with open arms...

Right now the various vendors seem to insist on their own proprietary everything which makes it hard to streamline your development toolchain. Many of the tools I've used are inseparably linked to a Windows-only GUI application.

The plan is to have a completely open source toolchain from the HDL to P&R.

https://github.com/haojunliu/OpenFPGA

https://www.synflow.com/#home-Synflow

http://legup.eecg.utoronto.ca/

The Leon3 GPL SoC might also make a good test case for you since they're designed for easy customization. Lots of academics use it for experiments.

http://www.gaisler.com/index.php/products/processors/leon3

You can do things in an FPGA that a CPU can't even touch, it can be configured to do massively parallel computations for example.

If Bitcoin is any example, GPU is faster than CPU, FPGA is faster than GPU, and ASIC is faster than FPGA. Each one is at least an order of magnitude faster than the other.

A GPU can do thousands of calculations in parallel, but an FPGA can do even more if you have enough gates to support it.

I haven't looked too closely at the SHA256 implementations for Bitcoin, but it is possible to not only do a lot of calculations in parallel, but also have them pipelined so each round of your logic is actually executing simultaneously on different data rather than sequentially.

I don't really know much about this aspect, could you elaborate? I'm genuinely curious.

Furthermore, FPGAs are inherently much more expensive for things like reprogramming, than just recompiling your application. Synthesis and place-and-route can take excessive amounts of time even for some kinds of small designs. (And for larger designs, you tend to do post-synthesis edits on the resulting gate netlists to fix problems if you can, in order to avoid the horrid turn around time of hours or days for your tools). The "flow" of debugging, synthesis, testing etc is all fundamentally different and has a substantially different kind of cost model.

This means many kind of "dream" ideas of on-the-fly reconfiguration "Just-in-Time"-ing your logic cells, based on things like hot, active datapaths -- is a bit difficult for all but the simplest designs, due to the simple overhead of the toolchain and design phase. That said, some simple designs are still incredibly useful!

What's more likely with these systems is you'll use, or develop, pre-baked sets of bitstreams to add in custom functionality for customers or yourselves on-demand, e.g. push out a whole fleet of Xeons, configure the cells of machines on the edge to do hardware VPN offload, configure backend machines that will run your databases with a different logic that your database engine can use to accelerate queries, etc.

Whether or not that will actually pan out remains to be seen, IMO. Large enterprises can definitely get over the hurdles of shitty EDA tools and very long timescales (days) for things like synthesis, but small businesses that may still be in a datacenter will probably want to stick with commercial hardware accelerators.

Note that I'm pretty new to FPGA-land, but this is my basic understanding and impressions, given some time with the tools. I do think FPGAs have not really hit their true potential, and I do think the shit tooling -- and frankly god awful learning materials -- has a bit to do with it, which drives away many people who could learn.

On the other hand: FPGAs and hardware design is so fundamentally different for most software programmers, there are simply things that, I think, cannot so easily be abstracted over at all -- and you have to accept at some level that the design, costs, and thought process is just different.

[1] The only actual open-source Verilog->Upload-to-board flow is IceStorm, here: http://www.clifford.at/icestorm/. This is only specifically for the iCE40 Lattice FPGAs; they are incredibly primitive and very puny compared to any modern Altera or Xilinx chip (only 8,000 LUTs!), but they can drive real designs, and it's all open source, at least.

Just as an example, I've been learning using IceStorm, purely because it's so much less shitty. When I tried Lattice's iCE40 software they provided, I had to immediately fix 2 bash scripts that couldn't detect my 4.x version kernel was "Linux", and THEN sed /bin/sh to /bin/bash in 20 more scripts __which used bash features__, just so that the Verilog synthesis tool they shipped actually worked. What the fuck.

Oh! Also, this was after I had to create a fake `eth0` device with a juked MAC address (an exact MAC being required for the licensing software), because systemd has different device names for ethernet interfaces based on the device (TBF, for a decent reason - hotplugging/OOO device attachment means you really want a deterministic naming scheme based on the card), but their tool can't handle that, it only expects eth0.

As a software programmer, my mind is blown by the idea of a 3GHz CPU. That's 3,000,000,000 cycles per second. The speed of light c = 299,792,458 meters per second. Which means that, in the time it takes to execute 1 cycle, 1/3,000,000,000 seconds -- light has moved approximately 0.0999m ~= 4 inches. Unbelievable. Computers are fast!

On the other hand... Once you begin to deal with FPGAs, you often run into "timing constraints" where your design cannot physically be mapped onto a board, because it would take too long for a clock signal (read: light) to traverse the silicon, along the path of the gates chosen by the tool. You figure this out after your tool took a long amount of time to synthesize. You suddenly wish the speed of light wasn't so goddamn slow.

In one aspect of life, the speed of light, and computers, are very fast, and I hate inefficiency. In another, the speed of light is just way too slow for me sometimes, and it's irritating beyond belief because my design would just look nicer if it weren't for those timing requirements requiring extra work.

How to reconcile this kind of bizarre self-realization is an exercise left to the reader.

Don't forget the niche nature of an FPGA, too. They are incredibly slow & power hungry compared to a dedicated CPU, so similar to the CPU/GPU split you find that only particular workloads are suitable.

You can get an iCE40 FPGA for ~$50 USD, or as low as $20. It'll take you probably 30 minutes to compile all the tools and install them (you'll spend at least 2x that much time just fucking with stupid, traditional EDA tools, trying to make sense of them, and you'll still do that more than once probably), and you're ready.

The learning material stuff is much more difficult... Frankly, just about every Verilog tutorial out there, IMO, totally sucks. And Verilog is its own special case of "terrible language" aside from that, which will warp your mind.

Did you just use an undeclared wire (literally the equivalent of using an undeclared variable in any programming language)? Don't worry: Verilog won't throw an error if you do that. Your design just won't work (??????).

If you're a "traditional" software programmer (I don't know how else to put it?) who's mostly worked in languages like C, Java, etc. then yes: just the conceptual change of hardware design will likely be difficult to overcome, but it is not insurmountable.

The actual "write the design" part hasn't been too bad for me - but that's because I don't write Verilog. I write my circuits in Haskell :) http://www.clash-lang.org -- it turns out Haskell is actually an OK language for describing sequential and combinatoral circuits in very concise way that embodies the problem domain very well -- and I have substantial Haskell experience. So I was able to get moving quickly, despite being 100% software person.

There are also a lot of other HDLs that will probably take the edge off, although learning and dealing with Verilog is basically inevitable, but I'd rather get accustomed to the domain than inflict self-pain.

MyHDL, which is an alternative written in Python, seems to be an oft-recommended starting point, and can output Verilog. Someone seems to even have a nice tool that will combine MyHDL with IceStorm in a tiny IDE! Seems like a great way to start -- https://github.com/nturley/synthia

What doesn't work is using an HDL to write as if it were software. It's just not.

[0] I'm talking about the RTL subset obviously

But it's not just about that... Frankly, most HDLs have absolutely poor abstraction capabilities, and are quite verbose. Sure, it isn't a software language, but that's a bit aside from the point. I can't even do things like write or use higher order functions, and most HDLs don't have very cheap things like data types to help enforce correctness (VHDL is more typed, but also pretty verbose) -- even when I reasonably understand the compilation model and how the resulting design will look, and know it's all synthesizable!

On top of that, simply due to language familiarity, it's simply much easier for me to structure hardware descriptions in terms of things like Haskell concepts, than directly in Verilog. It wouldn't be impossible for me to do it in Verilog, though -- I'm just more familiar with other things!

At some level this is a bit of laziness, but at another, it's a bit of "the devil you know". I do know enough Verilog to get by of course, and do make sure the output isn't completely insane. And more advanced designs will certainly require me going deeper into these realms where necessary.

I've recently been writing a tiny 16-bit processor with Haskell, and this kind of abstraction capability has been hugely important for me in motivation, because it's simply much easier for me to remember, describe and reason about at that level. It's simply much easier for me to think about my 2-port read, 1-port write register file, mirrored across two BRAMs, when it looks as nice and simple as this: https://gist.github.com/thoughtpolice/99202729866a865806fd6d..., and that code turns into the kind of Verilog you'd expect to write by hand, for the synthesis tool to infer the BRAMs automatically (you can, of course, also use the direct cell library primitive).

That said -- HDL choice is really only one part of the overall process... I've still got to have post-synthesis and post-PNR simulation test benches, actual synthesizable test benches to image to the board, etc... Lots of things to do. I think it's an important choice (BlueSpec is another example here, which most people I've known to use it having positive praise), but only one piece of the overall process, and grasping the whole process is still something I'm grappling with.

https://github.com/cornell-brg/pymtl

Found http://ucsbarchlab.github.io/PyRTL/ which has a good overview of these sorts of projects.

Actually a couple of YouTube videos can get you up and running pretty fast. Verilog is quite simple and doing things like writing your own VGA adapter is pretty straightforward and teaches you a lot and is a lot of fun.

FPGAs are best when deployed on streaming tasks. And one would think inference would be just that, yet the published performance numbers are on par with 2012 GPUs. That said, if they had as efficient a memory architecture as GPUs do, things could get interesting down the road. But by then I suspect ASICs (including one from NVIDIA) will be the new kings.

Yes, I suspect Nvidia has been developing/prototyping a Deep Learning ASIC for some time now. The power savings from an ASIC (particularly for inference) are just too massive to ignore.

Nvidia also seems to be involved in an inference only accelerator from Stanford called EIE (excellent paper here - https://arxiv.org/pdf/1602.01528v2.pdf).

Edit @protomok thanks for the link, it is an interesting paper!

As for FPGAs, anybody who actually used one, especially for more than a toy problem, will tell you that the experience is nowhere near that. Plus, at the moment, we are comparing a solution that could possibly perhaps materialise with something that will simply appear as part of the next CPU.