Did we step into a dimension where only "How do I print('hello world')?" is a valid question while I wasn't watching, because it has a trivial one-line answer?
Hard questions doesn't mean they're bad, it just means many people aren't competent answer them. The same goes for obscure questions; there might just not be many people who care, but the question itself is entirely valid.
Does that mean they're not suitable for S/O?
I... can't believe anyone seriously believes that hard niche problems are too obscure or too hard for S/O to be bothered to grace themselves with.
It's absurd.
It just baffles me that a question that might take some effort to figure an answer out to might 'not be suitable' to S/O.
Almost any hardware, .NET runs on x86, AMD64, ARMv7 and ARM64 processors. Almost any desktop or server OS, .NET runs on reasonably modern versions of Windows, Linux and MacOS.
The complete source code of the server is in the question.
> .NET runs on x86, AMD64, ARMv7 and ARM64 processors. Almost any desktop or server OS, .NET runs on reasonably modern versions of Windows, Linux and MacOS.
I'm not really asking where .NET runs; I'm asking what is the environment to reproduce it in? If it only affects certain ones it's a waste of time to just make people guess.
> The complete source code of the server is in the question.
The .NET runtime is cross-platform, the lower level asp-net infrastructure is included in the runtime. The higher level CoreWCF RPC library OP uses is written fully in C#. I would expect it to run in all environments supported by the .NET runtime.
Personally, I have reproduced the bug on Windows 10 running on AMD64 processor. BTW, the code in the question only communicates to localhost address i.e. doesn’t need any networking on the computer.
The problem with the question as originally asked is not the difficulty or "obscurity".
The problem is complexity and scope.
We don't debug code for others. We expect them to find the specific part of the code that is causing a problem and showcase a minimal reproducible example. For performance issues, we expect them to profile code and isolate bottlenecks - and then they can ask a hard, obscure question about the bottleneck. Or a very easy one, as long as it's something that could make sense to ask after putting in the effort.
In short: we're looking for a question, not a problem. Stack Overflow "can't be bothered to grace itself with" hard niche problems, or with easy common problems. But it is about answering the question that results from an analysis of a problem. Whether that's understanding the exact semantics of argument passing, or just wanting to know how to concatenate lists.
And we're looking for one question at a time. If there are multiple issues in a piece of code, they need to be isolated and asked about separately. If the task clearly breaks down into a series of steps in one obvious way, then you need to figure out which of those steps is actually causing a problem first, and ask about whichever steps separately. (Or better yet, find the existing Q&A.)
(Questions seeking to figure out an algorithm are usually okay, but usually better asked on e.g. cs.stackexchange.com. And usually, an algorithm worth asking about isn't just "do X, then do Y, then do Z".)
Stack Overflow is full of highly competent people who are yearning for questions that demand their specific expertise - recently, not just in the 2010s.
Most questions I've asked since 2020 were deliberate hooks to deal with common beginner-level issues or close FAQs that didn't already have a clear duplicate target. (I've stopped contributing new Q&A, but still occasionally help out with curation tasks like editing.) But I asked https://stackoverflow.com/questions/75677825 because I actually wanted an answer, and it's an instructive example here.
Answering it required detailed expert-level knowledge of modern CPU architectures and reverse engineering of the Python implementation. Asking it required noticing a performance issue, then putting extensive effort into simplifying the examples as much as possible and diagnosing the exact qualities of the input that degrade performance - as well as ruling out other simple explanations and citing the existing Q&A about those.
But demonstrating it requires nothing more than a few invocations of the `timeit` standard library module.
If that is the current culture on SO, that's very unfortunate. Back when I was active on it - in late 00s to mid 10s - I absolutely did "debug code for others" when the problem was interesting enough to warrant it.
> Back when I was active on it - in late 00s to mid 10s - I absolutely did "debug code for others" when the problem was interesting enough to warrant it.
Yes, lots of people did, including myself.
When I got tired of it, and then came back years later and seen what had happened to the Q&A, I understood that it had been a mistake to do so, and eventually realized - through extensive research on the site meta, Stack Exchange meta, etc. - that it was the same mistake that the site had originally specifically sought to avoid.
And I saw that there had been years of arguing over the labels for close reasons - leading for example to the retirement of "not a real question", and the more or less direct replacement of "too broad" with "needs more focus", and the rather more approximate replacement of "too localized" with "not reproducible or caused by a typo" - because of a collective realization of the real purpose of closing questions, and of the value of being selective. Not just in terms of answer-writers getting frustrated - because we also discovered that some people just don't, and are happy to spend amazing amounts of time trying to read the minds of people who can barely put together a coherent sentence and turn out to be asking about the same common issue for the N+1th time.
And I saw that there had been years of arguing over whether expecting a "minimum level of understanding" was the right phrasing (it's really about the effect that has on question-writing, not just on whether the OP is likely to be able to understand a correctly-written answer - although that does weigh in the calculation), which led to a trial close reason being implemented for a couple of weeks in 2013.
And I saw that by the time I got back, quite a few things had been more or less settled and reasoned out, but that the general community was not on the same page as the people who had been actually thinking about these things. Obviously I didn't agree with everything immediately, and obviously there are still disagreements among those who are broadly speaking on the same page. But I could see the vision.
And I realized that before I left, I had been using the site without putting any effort into trying to understand it. Like most users, I had been "the general community".
(And then I saw that there was tons of unpleasantness between users and the company itself, and unfit-for-purpose site software, and a totally broken reputation system that had never been properly reconsidered. Which is how I ended up checking out Codidact as an alternative. But most of what I say about Stack Overflow isn't really about Stack Overflow; it's about "the Stack Exchange model" - the "Q&A site" as I understand it - which alternative sites still implement.)
We didn't get here spontaneously. Everything was extensively discussed and the discussion is extensively documented, with carefully considered rationale where possible.
> If that is the current culture on SO, that's very unfortunate.
You’re being down voted because you’re not saying anything meaningful.
Yes, you can argue that [person] is [performing an action] because they believe, from their POV that [reason1, reason2, reason3].
> Or does [what person believes] not matter when they act upon it?
Yes.
What people choose to believe is distinct from fundamental baseline reality.
Let me put it another way for you; if I believe that fairies have invaded from space and I go out smashing peoples cars because, I personally, believe that this will make the fairies go home…
…does it help to argue about whether I believe in fairies or not?
It does not.
The arguement must be about whether fairies exist in baseline reality or not.
What I believe is not a point worth discussing.
…so, to take a step back to your argument:
Does he believe this will help? Who. Gives. A. Flying. Truck? Does it matter what he believes? Can we speculate what he thinks? It’s a useless and meaningless exercise and a logical fallacy; because anything can be justified if the only criteria are “you believe it will work”.
The discussion worth having is, in baseline reality, will it actually help?
Which is what the post you are replying to is addressing; but instead or following that up, you’ve moved this discussion into a meaningless sub thread of unprovable points about what people may or may not believe.
This is a concept that is seemingly alien to Americans.
The consequences of your actions matter even if you disagree. When your actions hurt people, you've still hurt people. Doesn't matter what you thought you were doing.
You see this kind of thinking through all levels of American life. You, personally, are the only person on the planet who matters, fuck everyone else and let them deal with the consequences. You run a red light and someone else gets T-boned and killed? That's their problem, you got to your destination 3 minutes faster.
The trump administration is simply the manifestation of how sick our country is.
It's going to take us generations to recover from this kind of societal illness, if we ever can.
They are experts in this field, and, unlike “random person on the internet who spent 2 minutes on google”, have informed opinions on this topic.
If you want a serious discussion on why fluoride is good or bad, that’s where you need to go.
Random person on the internet is very easy to disagree with, because we’re all idiots right? It’s a very easy lazy way of self confirmation.
…but if you are serious about critically considering the issue and facing your own biases, talk to an actual topic expert.
My dentist told me he had carefully reviewed the literature and determined to his satisfaction that public fluoridated water was in the best interests of public health, currently. He offered to share some reading that he was convinced by.
You can’t really ask for more that that.
Discussing this here is a bit like protesting by posting on social media; yes, I suppose it’s better than doing nothing and not engaging with the topic at all… but only barely, and not in any meaningful way.
That study is taken grossly out of context. It doesn’t claim what people claim it does and even the study states that the quality of the data on which the weaker claim was made is suspect.
The bigger issue is that we have vast amounts of scientific data and empirical evidence around fluoride toxicity. People are injured and die due to fluorine exposure, we understand how it interacts with biology. Any mechanism of action that can support the hypothesis that fluorine causes brain damage necessarily invalidates all of this evidence and is difficult to explain as a matter of basic chemistry.
And then we have to explain why fluoride in water has this effect but the much higher levels of fluoride in food does not.
Fluoridating municipal water may not offer much benefit but there is no credible science that it is actually harmful. Large regions of the world have water that naturally has far higher fluorine content than municipal water and there is no evidence of IQ reduction in these regions either.
If you're not prepared to listen to an expert, and that's what your dentist is on this topic, then nothing I, or anyone else can say, makes any difference to you.
At some point, you have to accept that your random wikipedia page and 5 minutes on google is not a convincing argument.
This is right up there in the conspiracy theory territory.
Rational discussion means listening to experts and admitting that you are not an expert.
What do you want me to say?
You aren't a qualified expert on this topic. If you want an expert opinion, talk to an expert, not some dubious fucking provenance wikipedia page.
Your dentist is not an expert in this — that’s like saying the guy implementing your frontend is an expert in design. Yes, they’re working in the space, but their job isn’t understanding the whole system.
If you’re this deep on the appeal to authority train, the NIH released a report in the last year linking fluoride exposure to moderate drops in IQ with moderate confidence.
It’s probably not the worst thing in the world, but is definitely not inert.
I am competent on this particular subject matter, I have worked in fluorine chemistry and am familiar with the biology and medical literature of fluorine toxicity. The report made much weaker claims than people seem to think.
There is a very serious mechanism of action problem. Fluorine poisoning is a thing that happens. The observed effects and empirical evidence, as well as the mechanisms of action that cause them, are incompatible with any mechanism of action that supports the hypothesis that it causes brain damage. Basically, it would invalidate the entire history of actual fluoride exposure.
The other serious problem is that people are exposed to far more fluorine through what they eat than through water. What is special about trace levels in municipal water? And many parts of the world have far higher natural fluoride levels in their water than any municipal water supply with no evidence of adverse consequences. This has been studied many times in many countries! In fact, the only consistent correlation with naturally high fluoride levels is better cardiovascular health (for which there is a known mechanism of action).
This notion that trace levels of fluoride in some municipal water is adversely impacting IQ based on thin evidence from the developing world is just the public health version of “faster than light neutrinos”. Someone thinks they measured it but it contradicts everything we know about the subject. The rational approach isn’t to discard everything we know without a hell of a lot more evidence.
I don’t think adding fluoride to municipal water does much these days but it also isn’t harming anyone.
It also seems to mirror the rhyme with the vaccine "debate."
That debate is framed around being vaccinated vs the scare of "vaccine caused autism" (or myocarditis), but that frame is missing the risk of things like measles.
Likewise tooth decay is not only expensive, but it can have dreadful health consequences if left unaddressed. Missing teeth is also socially costly. Being poor or "ugly" or poor looking is a serious adverse health consequence. Imagine parents barely making ends meet or working multiple jobs. It's easy to imagine disadvantaged kids missing out on dental care.
I also explicitly remember reading multiple reports of poor tooth health correlating with dementia development. I've also read that serious infections of any sort can harm IQ.
Sure, but we need to look at this from the other side, too. Does fluoridating water provide benefits? I think it's safe to say it did way back when we started doing it. But we didn't have fluoride toothpaste back then. Putting fluoride in the water is presumably more costly than not doing it. If it's actually providing benefits, and the risk of harm is below some very low threshold, then sure, let's keep doing it. But is it actually providing benefits?
I would be really surprised if dentists had much expertise on the impact of fluorine on physiology or the mechanisms of action for its toxicity. They know what it does to your teeth, and maybe that it is known to have positive effects for cardiovascular health, but that is about the extent of it. The systematic effects on the rest of your body are outside their domain.
Chemists who work in fluorine chemistry on the other hand have to become experts on the biological effects of fluorine exposure. Small and seemingly innocuous exposures can do a lot of damage and kill you, though not in a way that lends any support to the idea that municipal fluoridation will harm you. If you do understand how it kills you (basically by being exceptionally narrowly focused on making free calcium ions and to a lesser extent magnesium ions biologically unavailable), it is hard to describe a chemically plausible scenario that somehow avoids this basic fact of chemistry. Fluoride behaves the same way outside the body.
Municipal water exposure is far below the noise floor for fluoride. Food has far higher levels of fluoride than municipal water and the body has ample excess calcium and magnesium to absorb the loss of bioavailability of a microscopic amount of those minerals. Humans consume calcium measured in grams per day, multiple orders of magnitude more than can be lost via municipal fluoridation. Natural dietary variation will have a far larger effect.
Who do you think conducted those peer-reviewed systematic reviews? I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
And I don't need an expert to tell me people should have the right to make their own medical decisions.
And finally, I live in a country where public health experts have decided against water fluoridation. This is represents the vast majority of countries. What now? Should I pick some other experts to listen to?
Who do you think conducted those peer-reviewed systematic reviews? I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
I don’t understand what you mean here. Are you just wholly rejecting the concept of expert knowledge, trials, meta analyses, basically the foundations of science, just because in order to participate in it you have to have tainted yourself by rigorously studying it?
You are not an expert in this field, and cherry-picking random articles in random journals does not make you an expert.
> Should I pick some other experts to listen to?
I think it's reasonably clear that you haven't spoken to an expert in this field.
> I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
Are you certain you're competent to review and understand the literature on the topic? It takes a lot of time and effort; that's what dentists do as a job. That's why they have to go to school. That's why random people on the internet do not do dentistry.
If you don't trust my dentist, then talk to your dentist.
This is literally my point: I'm not telling you how it is; I'm telling you, talk to someone who knows what they're talking about; and, don't believe that you are an expert because you put some trivial amount of effort into investigating it yourself.
I'm also not convinced that a dentist is credibly an expert here. Sure, I would absolutely expect my dentist to understand what benefits fluoridated water might provide to my teeth. I would not, for example, expect my dentist to be an expert in whether or not fluoridated water could cause damage to other parts of my body.
My previous dentist pushed these $80 (not covered by insurance) fluoride treatments on every cleaning visit. There's no research that shows much of anything about their effectiveness (good or bad). Yet they push them anyway, because it (their words) might help and probably won't harm. That doesn't give me a good feeling about their competence to have an expert opinion on this sort of thing.
I would, however, trust the opinion of someone who is doing medical/dental research, and holds a doctorate in a relevant field.
> Talk to your dentist. They are experts in this field
No they are not. The are experts are filling cavities and treatment. They have no additional knowledge of fluoride in water vs any other interested person.
For that you need to talk to someone in research, which is not someone seeing patients.
The vast majority of dentists are not public health experts, and will have little to offer other than “exposing your teeth to fluoride regularly is good”.
> However, what's wrong with allowing another app to post messages to my messages?
> If I don't want it, let me turn them off.
Can you it off for anyone sending you messages too?
That's the issue; you not wanting to use it does not mean that spammers won't use it.
That's the problem. You can't have nice things if some people can use it to abuse the system; and there are a lot of people who will.
> But my point is this isn't something unreasonable for a user to want.
This ignores the reality which is that doing it in a way that gives a nice user experience without an enormously painful security issue is really non trivial.
Maybe it's OK to have the choice?
...
If you love your android phone, don't care about iOS, don't like iphones.... why do you care? I mean, why does it upset android users when they see this sort of thing for people using iphones?
It mystifies me. If you love you phone, and you think it's better, then use it.
Automating imessages has been an official thing in macos since ages that i know of, but it is done on a computer rather than a phone. The argument that opening up automation for imessage will increase spam does not hold, just because automation is already opened up, thus whatever spam this allows or not is already here.
EDIT: example script to run from a mac terminal:
osascript -e 'tell application "Messages" to send "$message" to buddy "+12345678" of (1st service whose service type = iMessage)'
Because running a parallel process is often difficult. In most cases, the question becomes:
So, how exactly is my app/whatever supposed to spin up a parallel process in the OS and then talk to it over IPC? How do you shut it down when the 'host' process dies?
Not vaguely. Not hand wave "just launch it". How exactly do you do it?
How do you do it in environments where that capability (spawning arbitrary processes) is limited? eg. mobile.
How do you package it so that you distribute it in parallel? Will it conflict with other applications that do the same thing?
When you look at, for example, a jupyter kernel, it is already a host process launched and managed by jupyter-lab or whatever, which talks via network chatter.
So now each kernel process has to manage another process, which it talks to via IPC?
...
Certainly, there are no obvious performance reasons to avoid IPC, but I think there are use cases where having the compiler embedded makes more sense.
> So, how exactly is my app/whatever supposed to spin up a parallel process in the OS and then talk to it over IPC?
Usually the very easiest way to do this is to launch the target as a subprocess and communicate over stdin/stdout. (Obviously, you can also negotiate things like shared memory buffers once you have a communication channel, but stdin/stdout is enough for a lot of stuff.)
> How do you shut it down when the 'host' process dies?
From the perspective of the parent process, you can go through some extra work to guarantee this if you want; every operating system has facilities for it. For example, in Linux, you can make use of PR_SET_PDEATHSIG. Actually using that facility properly is a bit trickier, but it does work.
However, since the child process, in this case, is aware that it is a child process, the best way to go about it would be to handle it cooperatively. If you're communicating over stdin/stdout, the child process's stdin will close when the parent process dies. This is portable across Windows and UNIX-likes. The child process can then exit.
> How do you do it in environments where that capability (spawning arbitrary processes) is limited? eg. mobile.
On Android, there is nothing special to do here as far as I know. You should be able to bundle and spawn a native process just fine. Go binaries are no exception.
On iOS, it is true that apps are not allowed to spawn child processes, as far as I am aware. On iOS you'd need a different strategy. If you still want a native code approach, though, it's more than doable. Since you're on iOS, you'll have some native code somewhere. You can compile Go code into a Clang-compatible static library archive, using -buildmode=c-archive. There's a bit more nuance to it to get something that will link properly in iOS, but it is supported by Go itself (Go supports iOS and Android in the toolchain and via gomobile.) Once you have something that can be linked into the process space, the old IPC approach would continue to work, with the semantic caveat that it's not technically interprocess anymore. This approach can also be used in any other situation you're doing native code, so as long as you can link C libraries.
If you're in an even more restrictive situation, like, I dunno, Cloudflare Pages Functions, you can use a WASM bundle. It comes at a performance hit, but given that the Go port of the TypeScript compiler is already roughly 3.5x faster than the TypeScript implementation, it probably will not be a huge issue compared to today's performance.
> How do you package it so that you distribute it in parallel? Will it conflict with other applications that do the same thing?
There are no particular complexities with distributing Go binaries. You need to ship a binary for each architecture and OS combination you want to support, but Go has relatively straight-forward cross-compiling, so this is usually very easy to do. (Rather unusually, it is even capable of cross-compiling to macOS and iOS from non-Apple platforms. Though I bet Zig can do this, too.) You just include the binary into your build. If you are using some bindings, I would expect the bindings to take care of this by default, making your resulting binaries "just work" as needed.
It will not conflict with other applications that do the same thing.
> When you look at, for example, a jupyter kernel, it is already a host process launched and managed by jupyter-lab or whatever, which talks via network chatter.
> So now each kernel process has to manage another process, which it talks to via IPC?
Yes, that's right: you would have to have another process for each existing process that needs its own compiler instance, if going with the IPC approach. However, unless we're talking about an obscene number of processes, this is probably not going to be much of an issue. If anything, keeping it out-of-process might help improve matters if it's currently doing things synchronously that could be asynchronous.
Of course, even though this isn't really much of an issue, you could still avoid it by going with another approach if it really was a huge problem. For example, assuming the respective Jupyter kernel already needs Node.JS in-process somehow, you could just as well have a version of tsc compiled into a Node-API module, and do everything in-process.
> Certainly, there are no obvious performance reasons to avoid IPC, but I think there are use cases where having the compiler embedded makes more sense.
Except for browsers and edge runtimes, it should be possible to make an embedded version of the compiler if it is necessary. I'm not sure if the TypeScript team will maintain such a version on their own, it remains to be seen exactly what approach they take for IPC.
I'm not a TypeScript Compiler developer, but I hope these answers are helpful in some way anyways.
Thanks for chiming in with these details, but I would just like to say:
> It will not conflict with other applications that do the same thing.
It is possible not to conflict with existing parallel deployments, but depending on your IPC mechanism, it is by no means assured when you're not forking and are instead launching an external process.
For example, it could by default bind a specific default port. This would work in the 'naive' situation where the client doesn't specify a port and no parallel instances are running. ...but if two instances are running, they'll both try to use the same port. Arbitrary applications can connect to the same port. Maybe you want to share a single compiler service instance between client apps in some cases?
Not conflicting is not a property of parallel binary deployment and communication via IPC by default.
IPC is, by definition intended to be accessible by other processes.
Jupyter kernels for example are launched with a specified port and a secret by cli argument if I recall correctly.
However, you'd have to rely on that mechanism being built into the typescript compiler service.
...ie. it's a bit complicated right?
Worth it for the speedup? I mean, sure. Obviously there is a reason people don't embed postgres. ...but they don't try to ship a copy of it along side their apps either (usually).
> Not conflicting is not a property of parallel binary deployment
I fail to see how starting another process under an OS like Linux or Windows can be conflicting. Don't share resources, and you're conflict-free.
> IPC is, by definition intended to be accessible by other processes
Yes, but you can limit the visibility of the IPC channel to a specific process, in the form of stdin/stdout pipe between processes, which is not shared by any other processes. This is enough of a channel to coordinate creation of a more efficient channel, e.g. a shmem region for high-bandwidth communication, or a Unix domain socket (under Linux, you can open a UDS completely outside of the filesystem tree), etc.
A Unix shell is a thing that spawns and communicates with running processes all day long, and I'm yet to hear about any conflicts arising from its normal use.
This seems like an oddly specific take on this topic.
You can get a conflicting resource in a shell by typing 'npm start' twice in two different shells, and it'll fail with 'port in use'.
My point is that you can do not conflicting IPC, but by default IPC is conflicting because it is intended to be.
You cannot bind the same port, semaphore, whatever if someone else is using it. That's the definition of having addressable IPC.
I don't think arguing otherwise is defensible or reasonable.
Having a concern that a network service might bind the same port as an other copy of the same network service deployed on the same target by another host is an entirely reasonable concern.
I think we're getting off into the woods here with an arbitrary 'die on this hill' point about semantics which I really don't care about.
TLDR: If you ship an IPC binary, you have to pay attention to these concerns. Pretending otherwise means you're not doing it properly.
It's not an idle concern; it's a real concern that real actual application developers have to worry about, in real world situations.
I've had to worry about it.
I think it's not unfair to think it's going to be more problematic than the current, very easy, embedded story, and it is a concern that simply does not exist when you embed a library instead of communicating using IPC.
> It is possible not to conflict with existing parallel deployments, but depending on your IPC mechanism, it is by no means assured when you're not forking and are instead launching an external process.
Sure, some IPC approaches can run into issues, such as using TCP connections over loopback. However, I'm describing an approach that should never conflict since the resources that are shared are inherited directly, and since the binary would be embedded in your application bundle and not shared with other programs on the system. A similar example would be language servers which often work this way: no need to worry about conflicts between different instances of language servers, different language servers, instances of different versions of the same language server, etc.
There's also some precedent for this approach since as far as I understand it, it's also what the Go-based ESBuild tool does[1], also popular in the Node.JS ecosystem (it is used by Vite.)
> For example, it could by default bind a specific default port. This would work in the 'naive' situation where the client doesn't specify a port and no parallel instances are running. ...but if two instances are running, they'll both try to use the same port. Arbitrary applications can connect to the same port. Maybe you want to share a single compiler service instance between client apps in some cases?
> Not conflicting is not a property of parallel binary deployment and communication via IPC by default.
> IPC is, by definition intended to be accessible by other processes.
Yes, although the set of processes which the IPC mechanism is designed to be accessible by can be bound to just one process, and there are cross-platform mechanisms to achieve this on popular desktop OSes. I can not speak for why one would choose TCP over stdin/stdout, but, I don't expect that tsc will pick a method of IPC that is flawed in this way, since it would not follow precedent anyway. (e.g. tsserver already uses stdio[2].)
> Jupyter kernels for example are launched with a specified port and a secret by cli argument if I recall correctly.
> However, you'd have to rely on that mechanism being built into the typescript compiler service.
> ...ie. it's a bit complicated right?
> Worth it for the speedup? I mean, sure. Obviously there is a reason people don't embed postgres. ...but they don't try to ship a copy of it along side their apps either (usually).
Well, I wouldn't honestly go as far as to say it's complicated. There's a ton of precedent for how to solve this issue without any conflict. I can not speak to why Jupyter kernels use TCP for IPC instead of stdio, I'm very sure they have reasons why it makes more sense in their case. For example, in some use cases it could be faster or perhaps just simpler to have multiple channels of communication, and doing this with multiple pipes to a subprocess is a little more complicated and less portable than stdio. Same for shared memory: You can always have a protocol to negotiate shared memory across some serial IPC mechanism, but you'll almost always need a couple different shared memory backends, and it adds some complexity. So that's one potential reason.
(edit: Another potential reason to use TCP sockets is, of course, if your "IPC" is going across the network sometimes. Maybe this is of interest for Jupyter, I don't know!)
That said, in this case, I think it's a non-issue. ESBuild and tsserver demonstrate sufficiently that communication over stdio is sufficient for these kinds of use cases.
And of course, even if the Jupyter kernel itself has to speak the TCP IPC protocols used by Jupyter, it can still subprocess a theoretical tsc and use stdio-based IPC. Not much complexity to speak of.
Also, unrelated, but it's funny you should say that about postgres, because actually there have been several different projects that deliver an "embeddable" subset of postgres. Of course, the reasoning for why you would not necessarily want to embed a database engine are quite a lot different from this, since in this case IPC is merely an implementation detail whereas in the database case the network protocol and centralized servers are essentially the entire point of the whole thing.
"no lines of code directly written, just directing the AI"
/skeptical face.
Without fail, every. single. person. I've met who says that, actually means "except for the code that I write", or "except for how I link the code it build together by hand".
If you are 50kloc in to a large complex project that you have literally written none of, and have, eg. used cursor to generate the code without any assistance... well, you should start a startup.
...because, that's what devin was supposed to be, and it was enormously and famously terrible at it.
So that would be either a) terribly exciting, or b) hyperbole.
I’m currently doing something very similar to what GP is doing - I’m building a hobby project that’s a desktop app with web frontend. It’s a map editor with a 3D view. My estimate is that 80-90% of the code was written by AI. Sure, I did have to intervene or write some more complex parts myself but it’s still exciting to me that in many cases it took just a single prompt to add a new feature to it or change existing behavior. Judging from the complexity of the project it would take me in the past 4-5x longer if I were to write it completely by hand. It’s a game changer for me.
> My estimate is that 80-90% of the code was written by AI
Nice! It is entirely reasonable both to do that and to be excited about it.
…buuut, if that’s what you’re doing, you should say so.
Not:
“no lines of code directly written, just directing the AI”
Because those (gluing together AI code by hand and having the agent do everything) are different things, and one of them is much much MUCH harder to get right than the other one.
That last 10-15%. Self driving cars are the same story right?
I don’t think this is a fair take. For self driving cars, you care about that because safety is involved and the reliability of the AI is the product itself.
For OP, the product is the product, how they got there is mostly irrelevant. We don’t really care what IDE they used (outside of being a tooling nerd).
AI is hard; edge cases are hard. AI sucks at edge cases.
Between AI for cars and AI for software the long tail of edge cases that have to be catered for is different, yes.
...but I'm sure the same will apply for AI for art (e.g. hands), and AI for (insert domain here).
Obviously no analogy is perfect, but I think you have to really make an effort to look away from reality not to see the glaringly obvious parallels in cars, art, programming, problem solving, robots, etc. where machine learning models struggle with edge cases.
Does the tooling they used matter? no, not at all.
...but if they've claimed to solve the 'edge case problem', they've done something really interesting. If not, they haven't.
So, don't claim to have done something really interesting if you haven't.
You can say "I've been using AI to build a blah blah blah. It's great!" and that's perfectly ok.
You have to go out of your way to say "I've been using an AI to build blah blah blah and I haven't written any of it, it's all generated by AI". <-- kinda attention seeking.
"no lines of code directly written" really? Why did you mention that? You got the AI to write your software for you? That sounds cool! Let's talk! Are you an AI consultant by any chance? (yes, they are). ...but.
No. You didn't. You really didn't. I'm completely happy to call people out for doing that; its not unfair at all.
That's the point of the experiment I'm doing, what it takes to get these things to be able to generate all the code, and I'm just directing.
I literally have not written a line of code. The AI agent configures the build systems. It executes the `go install` command. It configures the infrastructure via terraform.
It takes a lot of reading of the code that's generated to see what I agree with or not, and redirecting refactorings. Understanding how to describe problem statements that are translated into design docs that are translated into task lists. It's still a lot of knowledge work on how to build software. But now I can do the coding that might have taken a day from those plans in 20 minutes.
Regarding startups, there's nothing here I'm doing that isn't just learning the tools of agentic coding. The business here might be advising people on how to do it themselves.
If you know how to architect code well, you can guide the AI to create smaller more targeted modules. That way as you 'write code with AI', you give it a targeted subset of the files to edit on each prompt.
In a way the AI becomes the dev and you become the code reviewer. Often as the AI is writing the code, you're thinking about the next step.
I'm sure there's a time and place for these things, but this sounds very much like the echo chamber I hear at work all the time.
Someone has a 'friend' who has a totally-not-publically-visible form where a chat bot interacts with the form and helps the user fill the form in.
...and users love it.
However, when really pressed, I've yet to encounter someone who can actually tell me specifically
1) What form it is (i.e. can I see it?)
2) How much effort it was to build that feature.
...because, the problem with this story is that what you're describing is a pretty hard problem to solve:
- An agent interacts with a user.
- The agent has free reign to fill out the form fields.
- Guided by the user, the agent helps will out form fields in a way which is both faster and more accurate than users typing into the field themselves.
- At any time the user can opt to stop interacting with the the agent and fill in the fields and the agent must understand what's happened independently of the chat context. i.e. The form state has to be part of the chat bot's context.
- At the end, the details filled in by the agent are distinguished from user inputs for user review.
It's not a trivial problem. It sounds like a trivial problem; the agent asks 'what sort of user are you?' and parses the answer into one of three enum values; Client, Foo, Bar -> and sets the field 'user type' to the value via a custom hook.
However, when you try to actually build such a system (as I have), then there are a lot of complicated edge cases, and users HATE it when the bot does the wrong thing, especially when they're primed to click 'that looks good to me' without actually reading what the agent did.
So.
Can you share an example?
What does 'and has a lot of usage' mean in this context? Has it increased the number of people filling in the form, or completing it correctly (or both?) ?
I'd love to see one that users like, because, oh boy, did they HATE the one we built.
At the end of the day, smart validation hints on form input fields are a lot of easier to implement, and are well understood by users of all types in my experience; it's just generally a better, normal way of improving form conversion rates which is well documented, understood and measurable using analytics.
...unless you specifically need to add "uses AI" to your slide deck for your next round of funding.
My partner has dyslexia and finds forms overwhelming. Chatbots break this down and (I suspect) give the same feeling of guidance. As for specific examples NHS has some terribly overwhelming forms and processes - image search IAPTUS.
Another example; I was part of a team that created a chatbot which helped navigate internal systems for call centre operators. If a customer called in, we would pick up on keywords and that provided quick links for the operator and pre-fill details like accounts etc. The operator could type questions too which would bring up the relevant docs or links. I did think looking into the UX would’ve been a better time spend and solved more problems as the system was chaos but “client wants”. What we built in the end did work well and reduced onboarding and training by 2 weeks.
You would need to spend thousands of dollars to become a customer, if you are not already one.
>An agent interacts with a user.
Correct, they are asked to describe their problem. There are some follow up questions, then some very specific questions if the form still isn't filled out.
>The agent has free reign to fill out the form fields.
Correct but there are actually very few free form fields and a lot of selections.
>Guided by the user, the agent helps will out form fields in a way which is more accurate than users typing into the field themselves.
Correct, the form is filled out correctly more often now
>Guided by the user, the agent helps will out form fields in a way which is faster than users typing into the field themselves.
No, I specifically said it is not. I can fill out a junk but valid form in about 10 seconds and valid with relevant data for testing in about 30 seconds. It is not a long form, but your selections will change the next selections. But I also helped build the form and have seen it go through every iteration.
>At any time the user can opt to stop interacting with the the agent and fill in the fields and the agent must understand what's happened independently of the chat context. i.e. The form state has to be part of the chat bot's context.
Would be a nice feature upgrade but if the user abandons the bot they just fill out the form as normal, same as if they decided to skip the bot at the beginning.
>At the end, the details filled in by the agent are distinguished from user inputs for user review.
Do you mean how do we know if the chat bot was used or whether it fills out the form. Both are trivial.
>Has it increased the number of people filling in the form, or completing it correctly (or both?) ?
The ideal case is that they never need to request help, but nearly all users will need help maybe once or twice a year unless something is really wrong. But yes, the number of users filling out the form incorrectly has decreased. Seems like the users don't mind spending 2-5 minutes per year chatting with the bot.
> You would need to spend thousands of dollars to become a customer, if you are not already one.
Can you be more specific?
Like, where specifically would I have to spend money to see this.
> Seems like the users don't mind spending 2-5 minutes per year chatting with the bot.
This seems like an enormous amount of effort to have gone to for a single form that people use once a year.
Did you roll out the chatbot assist to other forms? If not, why not? If so, are any of those forms easier to get access to that we can see either live or in a video?
Honestly, this is why I get frustrated with these conversations.
If it works so well, why isn't this sort of thing rolled out in many, visible, obvious places. Why is it hidden away behind paywalls and internal systems where no one can see it?
Why isn't everyone doing it? I've visited 4 websites today which had a chat bot on them, and none of them had a way for the bot to interact with anything on the page other than their own chat context.
Like I said, I'm sure it works to some degree, and varying degrees depending how much effort you put into it... but I'm frustrated I can never find someone who's so proud of it working they can go HERE, look at THIS example of it working.
Does anyone have an example we can actually look at?
If you’re a for profit company trying to raise funding and fend off skepticism that your models really aren’t that much better than any one else’s, then…
It would be dishonest, but as long as no one found out until after you closed your funding round, there’s plenty of reason you might do this.
It comes down to caring about benchmarks and integrity or caring about piles of money.
Judge for yourself which one they chose.
Perhaps they didn’t train on it.
Who knows?
It’s fair to be skeptical though, under the circumstances.
We already have agentic systems; they're not particularly impressive (1).
There's no specific reason to expect them to get better.
Things that will shift the status quo are: MCST-LLMs (like with ARC-AGI) and Much Bigger LLMs (like GPT-5, if they ever turn up) or some completely novel architecture.
[1] - It's provable; if just chaining LLMs are a particular size into agentic systems could scale indefinitely, then you could use a 1-param LLM and get AGI. You can't. QED. Chaining LLMs with agentic systems has a capped maximum level of function which we basically already see with the current LLMs.
ie. Adding 'agentic' to your system has a finite, probably already reached, upper bound of value.
> It's provable; if just chaining LLMs are a particular size into agentic systems could scale indefinitely, then you could use a 1-param LLM and get AGI. You can't. QED.
Perhaps I missunderstand your reply, but that has not been my experience at all.
There are 3 types of "agentic" behaviour that has worked for a while for me, and I don't know how else it would work without "agents":
1. Task decomposition - this was my manual flow since pre-chatgpt models: a) provide an overview of topic x with chapter names; b) expand on chapter 1 ... n ; c) make a summary of each chapter; d) make an introduction based on the summaries. I now have an "agent" that does that w/ minimal scripting and no "libraries". Just pure python control loop.
This gets me pretty reasonable documents for my daily needs.
2. tool use (search, db queries, API hits). I don't know how you'd use an LLM without this functionality. And chaining them into flows absolutely works.
3. coding. I use the following "flow" -> input a paragraph or 2 about what I want, send that + some embedding-based context from the codebase to an LLM (3.5 or 4o, recently o1 or gemini) -> get code -> run code -> /terminal if error -> paste results -> re-iterate if needed. This flow really works today, especially with 3.5. In my testing it needs somewhere under 3 "iterations" to "get" what's needed in more than 80% of the cases. I intervene in the rest of 20%.
Haha, yes! I'm trying it out and been loving it so far. I found that I go there for most of my eda scripts these days. I do a lot of datasets collection and exploration, and it's amazing that I can now type one paragraph and get pretty much what it would have taken me ~30 min to code myself. Claude 3.5 is great for most exploration tasks, and the flow of "this doesn't work /terminal" + claude using prints to debug is really starting to come together.
I use zed for this, cursor for my more involved sessions and aider + vscode + continue for local stuff when I want to see how far along local models have come. Haven't tried cline yet, but heard great stuff.
I didn’t say they don’t work, I said there is an upper bound on the function they provide.
If a discrete system can be composed of multiple LLMs the upper bound on the function they provide is by the function of the LLM, not the number of agents.
Ie. We have agentic systems.
Saying “wait till you see those agentic systems!” is like saying “wait til you see those c++ programs!”
Yes. I see them. Mmm. Ok. I don’t think I’m going to be surprised by seeing them doing exactly the same things in a year.
The impressive part in a year will the non agentic part of things.
Ie. Explicitly; if the underlying LLMs dont get any better, there is no reason to expect the system built out of them to get any better.
If that was untrue, you would expect to be able to build agentic systems out of much smaller LLMs, but that overwhelmingly doesn’t work.
> if the underlying LLMs dont get any better, there is no reason to expect the system built out of them to get any better.
Actually o1, o3 are doing exactly this, and very well. I.e. explicitly: by proper orchestration the same LLM can do much better job. There is a price, but...
> you would expect to be able to build agentic systems out of much smaller LLMs
Good point, it should be possible to do it on a high-end pc or even embedded.
They are not mutually exclusive. Likely we'll get more clear separation of architecture and underlying technology. In this case agents (i.e. architecture) can use different technologies or mix of them. Including 'AI' and algorithms. The trick is to make them work together.
1) clearly technical
2) reproducible
3) has a clear failure condition
Not be a suitable candidate for S/O?
Did we step into a dimension where only "How do I print('hello world')?" is a valid question while I wasn't watching, because it has a trivial one-line answer?
Hard questions doesn't mean they're bad, it just means many people aren't competent answer them. The same goes for obscure questions; there might just not be many people who care, but the question itself is entirely valid.
Does that mean they're not suitable for S/O?
I... can't believe anyone seriously believes that hard niche problems are too obscure or too hard for S/O to be bothered to grace themselves with.
It's absurd.
It just baffles me that a question that might take some effort to figure an answer out to might 'not be suitable' to S/O.