HN user

cabacon

819 karma
Posts12
Comments96
View on HN

I have a kid in high school who uses LLMs to get feedback on essays he has written. It will come back with responses like "you failed to give good evidence to support your point that [X]", or "most readers prefer you to include more elaboration on how you changed subject from [Y] to [Z]".

You (and another respondent) both cite the case where someone unthinkingly generates a large swath of text using the LLM, but that's not the only modality for incorporating LLMs into writing. I'm with you both on your examples, fwiw, I just think that only thinking about that way of using LLMs for writing is putting on blinders to the productive ways that they can be used.

It feels to me like people are reacting to the idea that we haven't figured out how to work it into our pedagogy, and that their existence hurts certain ways we've become accustomed to measuring people having learned what we intended them to learn. There's certainly a lot of societal adaptation that should put guardrails around their utility to us, but when I see "They will make us dumb!" it just sets of a contrarian reaction in me.

I guess my point is that the argument being made is "if you lift dumbbells with a forklift, you aren't getting strong by exercising". And that's correct. But that doesn't mean that the existence of forklifts makes us weaker.

So, I guess I'm just saying that LLMs are a tool like any other. Their existence doesn't make you worse at what they do unless you forgo thinking when you use them. You can use a calculator to efficiently solve a wrong equation - you have to think about what it is going to solve for you. You can use an LLM to make a bad argument for you - you have to think about the inputs you're going to have it output for you.

I was just feeling anti-alarmist-headline - there's no intrinsic reason we'd get dumber because LLMs exist. We could, but I think history has shown that this kind of alarmism doesn't come to fruition.

Plato's _Phaedrus_ features Socrates arguing against writing; "They will cease to exercise memory because they rely on that which is written, calling things to remembrance no longer from within themselves, but by means of external marks."

I have heard people argue that the use of calculators (and later, specifically graphing calculators) would make people worse at math; quick searching found papers like https://files.eric.ed.gov/fulltext/ED525547.pdf discussing the topic.

I can't see how the "LLMs make us dumber" argument is different than those. I think calculators are a great tool, and people trained in a calculator-having environment certainly seem to be able to do math. I can't see that writing has done anything but improve our ability to reason over time. What makes LLMs different?

I worked at a supercomputing facility for a few years. The codes are typically decades old, maintained by hundreds of people over the years. By and large, they understand their performance profiles, and are working to squeeze as much out of the code as they can.

In addition, the performance engineers tend to be employed by the facilities, not the computational scientists. They're the ones who do a bunch of legwork of profiling the existing code on their new platform, and figuring out how to squeeze any machine-specific performance out of the code.

A lot of these codes are time-marching PDE solvers that do a bunch of matrix math to advance the simulation, so the kernel of the code is responsible for a vast majority of the time spent during a job. So it's not necessarily a huge chunk of code that needs to be tuned to wring better performance out of the machine.

The parallel communication they do is also to an API, not an ABI - the supercomputing vendors drop in the optimizations in the build of the library for their machine, to take advantage of network-specific optimizations for various communications patterns. If you express your code in the most-specific function (doing a collective all-to-all explicitly, say, rather than building your own all-to-all out of the point-to-point primitive) the MPI build can insert optimized code for those cases.

There's some misalignment because the facility will be in the top 500 for a few years, while the code lives on and on and on. If your supercomputer architecture is really out of left field (https://en.wikipedia.org/wiki/Roadrunner_(supercomputer)) it's not going to be super worth it for people to try to run on it without porting support from the facility.

Yes, absolutely. They did something like this at the Sun Microsystems field office outside of Chicago while I worked there. You would log into a sunray with your smartcard and pick up whatever you had left behind in your session, with no permanent desk assignment.

It was unpopular, to say the least. Your personal belongings went into a pedestal on wheels that you could take to whichever workspace you wound up at that day. This was in 2000/2001 or so.

Truth be told, I don't think I'm calibrated on the question yet; I've only used it twice. In one org, there was a shining star who attracted all the answers. In the other org, someone laughed because of the number of good answers, and started rattling off names and reasons.

In hindsight, I wish I'd had enough experience with the question and possible scenarios to ask for a second answer from people in the first org; I suspect there were more good answers available, but one obvious answer that everyone snapped to first.

My favorite interviewing question as an IC was "Tell me about someone on your team you admire". It let me learn about what people valued based on why people were admired, and gave some depth-of-bench sense whether there were lots of distinct names, or if everyone was in awe of the one good person on the team.

If you're looking for cross-team health, maybe you could adapt it to "Tell me about someone on the other team that you admire?"

Regarding "theoretical best", I think that is "in the absence of mitigations". I think you can build a service with a higher SLA than one of its dependencies, but only if you recognize that impedance mismatch and build in defenses.

As a contrived example, if you've got a microservice that provides data FOO about a request that isn't actually end-user critical, you can mitigate your dependency on it by allowing your top-level request to succeed even if the FOO data is missing. Or maybe you can paper over blips of unavailability with cached data.

But, yes, know what you depend on and how reliable they are, then see if you need to take more action than that if your target is higher than the computed target.

See also a very nice video from ClojureWest about queues in system architectures: https://www.youtube.com/watch?v=1bNOO3xxMc0

The queue are everywhere - your messaging queue, the threadpool, the hardware threads, and other layers of the stack and APIs you use. The video adds the interesting detail that as you add more tellers (workers) you learn of impending disaster only in the outlier p99 (or higher) latencies; by the time your p85 latency rises, you're already about to stall out.

Fortress (http://en.wikipedia.org/wiki/Fortress_(programming_language)) and X10 (http://en.wikipedia.org/wiki/X10_(programming_language)) were the other two languages that came out of the DOE HPCS program (http://en.wikipedia.org/wiki/High_Productivity_Computing_Sys...) that might be interesting if you liked Chapel.

Other aiming-for-HPC languages include co-array Fortran (http://en.wikipedia.org/wiki/Coarray_Fortran) and Unified Parallel C (http://en.wikipedia.org/wiki/Unified_Parallel_C).

I never really saw any of them while working in HPC, though. It was just Fortran, C, and sometimes Python. The Python would really just call out via SWIG to a C function for the numeric kernel.

I clicked on this topic in order to make this suggestion. To expand on it a little bit, I was a math major and read Spivak's 'Calculus' after I had already taken real analysis. I found it delightful - it really approaches the topics from first principles and unlike many calculus textbooks actually goes through the effort of presenting proofs of the theorems. Highly recommended.

As some recreational reading, less suiting the original request, I very much enjoyed David Foster Wallace's 'Everything and More: A Compact History of Infinity' (http://www.amazon.com/Everything-More-Compact-History-Infini...). DFW is not for everyone, but I enjoyed it a lot. Maybe just check it out of the library first to see if it's for you.

The Graded Go Problems for Beginners (http://www.amazon.com/Graded-Problems-Beginners-Beginner-Ele...) has four volumes of increasingly difficult tactical problems. For the strategic side of things, I enjoyed Janice Kim's Learn To Play Go series, which has five or more volumes (http://www.amazon.com/Learn-Play-Go-Masters-Ultimate/dp/1453...)

And, of course, with Go you have a nice progression from learning to play on the 9x9 board for tactics, the 13x13 board to begin learning strategy, and the 19x19 board to play the real game. And thanks to the handicapping system, you can play much stronger players with both of you playing your hardest and both with a chance to win.

You might also enjoy http://www.youtube.com/user/kingscrusher

He comments on professional matches, but the part of his feed that I enjoy are the 1/3/5 minute time control games he plays. He is very good at articulating his thoughts during the game, and I find that much more engaging that listening to analysis of alternate lines that's more common in commentated chess matches.

GNU APL 1.0 13 years ago

I mean, the J Software app is basically that, although J instead of APL. The terseness makes for a pretty good programming environment despite the slow input speed of the virtual keyboard. You don't get the unicode APL customisation you're talking about, but it's pretty close.

The esotropia was diagnosed when I was a kid. In fact, the "visual specialist" I visited as an adult was actually a pediatric doctor, because they're the ones who have the most experience with esotropias. I don't have any memory of being diagnosed with it; it happened when I was 3 or 4, I believe. My left eye is also mildly dominant; if I'm looking straight ahead it will tend to win control. When it was diagnosed, they did an eye surgery to correct the tracking of the off-eye, and they tried to get me to wear glasses to further battle against eye-dominance, though I was a reluctant participant in that experience.

I learned the alternating esotropia name from my parents, probably during high school or so. I don't think I was able to name it before that, and I don't remember the context in which they shared it. Probably I was complaining about the stereograms that were popular at the time; I have never been able to see anything in those.

Aside from what I've mentioned so far, I also get a free bonus of driving my wife a little crazy; she always tries to figure out which of my eyes I'm looking out of when we're talking face-to-face. It's nice to have a bit of novelty that is, all-in-all, not really that big of a deal. It's fun to talk about, though, as evidenced by the popularity of this thread.

That lines up with my experience. The alternating esotropia means that at any time one of my eyes acts as dominant, but it will change based on which direction I look and is also under voluntary control.

I have played ultimate frisbee for years quite successfully, and people were usually surprised when I mentioned I have no depth perception. I've met another A.E. person who was a good softball player. The hard part is when I have to look up at blue sky to catch something; the size difference between "can jump to catch it and cannot" is not very big, and there are no parallax/overlapping cues to draw on.

Interestingly, one friend said "Oh, that explains it" when he learned about my eyes. He noticed that I never look into a cup or glass straight-on when filling it, but instead look at it from the side so I can see how full it is. The growth of the circle of the top-of-liquid is small enough that I will heavily underfill a glass rather than risk spilling. As you suggest, it's not deep life-changing stuff, but it is quite a novelty!

Super fun stuff. I have alternating esotropia (http://en.wikipedia.org/wiki/Esotropia) and also cannot see in stereo in normal life. 3D movies that rely on filters or polarisation also do not work for me. I went to a supercomputing demo of a 3d visualisation company that used occlusion like Rift apparently does, and it worked! It was really mind-bending. They were showing a visualisation of a variable in two dimensions, so they displayed a 3d surface. (I believe this was stuff targeted at the oil/gas industry)

My sensation was that given the size of the thing, it should not all have fit in front of me. That is, given how far away the back was, and how large it looked, the front of it should have been behind my head, but it wasn't. In a later meeting with a visual specialist, we confirmed that this was typical for people who haven't experienced 3d to feel about 3d. We also convinced ourselves that there was no way for me to get that with just corrective lenses.

How fun for this tech to hit the mainstream! For reference, the older tech was based on, I believe, the CAVE stuff (http://en.wikipedia.org/wiki/Cave_automatic_virtual_environm...)

If you're going to take that point of view, I guess I'd like to hear more about why you think Janus is a piece of crap. I understand the POV of people who say that learning fundamentals is the place to start, rather than starting with the extensions, okay. But for someone who knows the editor but isn't that plugged in to the vimscript ecosystem, what's wrong with aggregating a number of useful and interesting plugins? I don't understand the vitriol.

I don't think I would have been as interested in reading this (interesting!) book if I hadn't seen the power of things like NERDTree and TagBar, and I wouldn't have seen those if I hadn't poked through Janus.

vimtutor is pretty good, actually.

Outside of that, http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n... has a nice explanation of the editing worldview, which ties in with Steve's quote in http://learnvimscriptthehardway.stevelosh.com/chapters/16.ht..., "The idea of operators and movements is one of the most important concepts in Vim, and it's one of the biggest reasons Vim is so efficient. We're going to practice defining new motions a bit more, because extending this powerful idea makes Vim even more powerful."

Check out http://www.moolenaar.net/habits.html, http://stackoverflow.com/questions/1218390/what-is-your-most..., and maybe http://vimcasts.org/episodes/archive?

I've been using it for about a decade, so I think I've lost the beginner's mind to evaluate whether these are really the right entry points. Lots of people are passionate about vim, though; some googling should find you the exercises that will help you the most.

This seems to be the perpetual back-and-forth that shows up; I searched "site:ycombinator.com janus" before I posted the link, and you'll find this exact same line in history.

For myself, I knew core-vim pretty well, and was coming back to it after taking textmate and sublime text for a spin. Janus was a fast way to bolt on the IDE-alikes I liked from ST2. It was, indeed, too much on a first go, and I uninstalled it. I am back to it, though, and appreciate that it brought together the "big guns" like fugitive, nerdtree, syntastic, &c. as well as things I'm not sure I would have found, like Tim Pope's excellent unimpaired plugin.

Doing things like vimtutor is great for a newbie, but I don't think I care as much whether they have Janus installed or not while they do it.

That reminds me of using Docbook to write the book, then using the various transformation engines to turn the docbook into PDF. I setup some docbook documentation that just used xsltproc to generate HTML and PDF from the same source. http://stackoverflow.com/questions/2615002/how-to-generate-p... has some notes about the process.

For my part, I enjoyed the semantic markup it gave for something as big as a book, with auto-generating index and glossary as well. It's a lot of work, but the output reflects it. Looking at the HTML in the first chapter there, the spans with "term" and "menuitem" make me think something like docbook is going on behind this too.

To seed a comment, here are some VIM links I have enjoyed recently: https://github.com/carlhuda/janus is an easy way to pick up some nice plugins. I found it overwhelming the first time I played with it, but I am back around to trying it again and liking it better this time.

A set of crazy tips that made me learn to love the g commands: http://www.rayninfo.co.uk/vimtips.html

I believe I went to that from http://vim.wikia.com/wiki/Vim_Tips_Wiki, which isn't as fun to navigate as I would like it to be.

I just wanted to say "Thanks!" for the mobile view. I have found HN to be difficult to read on my ipod touch, and I'm glad you're working on fixing it up. I have nothing to say about the million-and-one suggestions about how it might be EVEN BETTER than what you've chosen to try for now, but I'm glad it's getting some attention.