You know there’s nothing stopping you from buying a server rack and loading that bad boy out with as much processing power as your heart desires, right?
Well, except money I guess, but according to this 1969 price list referenced on Wikipedia, a base model PDP-11 with cabinet would run you around $11,500. Adjusted for inflation, that’s about 95 grand. You could put together one hell of a home server for that kind of money.
Have you considered writing your own projects that you have to hide from your employers, and be careful with whom you discuss, so as to avoid the legal complications of the company owning your work?
I never looked into this, so I have some questions.
Isn’t the overhead of a new function every time going to slow it down? Like I know that LLVM has special instructions for Haskell-functions to reduce overhead, but there is still more overhead than with a branch, right? And if you don’t use Haskell, the overhead is pretty extensive, pushing all registers on the stack, calling new function, push buffer-overflow protection and eventual return and pop everything again. Plus all the other stuff (kinda language dependent).
I don’t understand what advantage is here, except for stuff where recursive makes sense due to being more dynamic.
Some languages have to optimize it with various tricks. There’s a good reason why I call heavily functional “programmer wankery”. It took me a while to run into an issue that was caused by a variable modified in a wrong way, which I fixed by saving the value of the variable before a call that seems to alter it. Probably I should have instead properly fix it so I could understand the actual root cause, but I have limited time to spend on things.
They aren’t talking about using recursion instead of loops. They are talking about the map method for iterators. For each element yielded by the iterator, map applies a specified function/closure and collects the results in a new iterator (usually a list). This is a functional programming pattern that’s common in many languages including Python and Rust.
This pattern has no risk of stack overflow since each invocation of the function is completed before the next invocation. The construct does expand to some sort of loop during execution. The only possible overhead is a single function call within the loop (whereas you could have written it as the loop body). However, that won’t be a problem if the compiler can inline the function.
The fact that this is functional programming creates additional avenues to optimize the program. For example, a chain of maps (or other iterator adaptors) can be intelligently combined into a single loop. In practice, this pattern is as fast as hand written loops.
A great point in favour of maps is that each iteration is independent, so could theoretically be executed in parallel. This heavily depends on the language implementation, though.
Imperative for loops have no guarantee at all that iterations could be executed in parallel.
You can do some (usually expensive, and never complete) analysis to find some cases, but smart compilers tend to work the best the dumbest you need them to be. Having a loop that you can just blindly parallelize will some times lead to it being parallel in practice, while having a loop where a PhD knows how to decide if you can parallelize will lead to sequential programs in practice.
Compiler optimizations like function inlining are your friend.
Especially in functional languages, there are a lot of tricks a compiler can use to output more efficient code due to not needing to worry about possible side effects.
Also, in a lot of cases the performance difference does not matter.
I’m not familiar with any special LLVM instructions for Haskell. Regardless, LLVM is not actually a commonly used backend for Haskell (even though you can) since it’s not great for optimizing the kind of code that Haskell produces. Generally, Haskell is compiled down to native code directly.
Haskell has a completely different execution model to imperative languages. In Haskell, almost everything is heap allocated, though there may be some limited use of stack allocation as an optimization where it’s safe. GHC has a number of aggressive optimizations it can do (that is, optimizations that are safe in Haskell thanks to purity that are unsafe in other languages) to make this quite efficient in practice. In particular, GHC can aggressively inline a lot more code than compilers for imperative languages can, which very often can eliminate the indirection associated with function calls entirely. gitlab.haskell.org/ghc/ghc/-/…/generated-code goes into a lot more depth about the execution model if you’re interested.
As for languages other than Haskell without such an execution model (especially imperative languages), it’s true that there can be the overhead you describe, which is why the vast majority of them use iterators to achieve the effect, which avoids the overhead. Rust (which has mapping/filtering, etc. as a pervasive part of its ecosystem) does this, for example, even though it’s a systems programming language with a great deal of focus on performance.
As for the advantage, it’s really about expressiveness and clarity of code, in addition to eliminating the bugs so often resulting from mutation.
So it basically enables some more compiler magic. As an embedded guy I’ll stay away from it, since I like my code being translated a bit more directly, but maybe I’ll look into the generated code and see if I can apply some of the ideas for optimizations in the future.
I looked at the post again and they do talk about recursion for looping (my other reply talks about map over an iterator). Languages that use recursion for looping (like scheme) use an optimization trick called ‘Tail Call Optimization’ (TCO). The idea is that if the last operation in a function is a recursive call (call to itself), you can skip all the complexities of a regular function call - like pushing variables to the stack and creating a new stack frame. This way, recursion becomes as performant as iteration and avoids problems like stack overflow.
Not just calls to self - any time a function’s last operation is to call another function and return its result (a tail call), tail call elimination can convert it to a goto/jump.
I once asked ChatGPT to generate some random numerical passwords as I was curious about its capabilities to generate random data. It told me that it couldn’t. I asked why it couldn’t (I knew why it was resisting but I wanted to see its response) and it promptly gave me a bunch of random numerical passwords.
It won’t generate random numbers. It’ll generate random numbers from its training data.
If it’s asked to generate passwords I wouldn’t be surprised if it generated lists of leaked passwords available online.
These models are created from masses of data scraped from the internet. Most of which is unreviewed and unverified. They really don’t want to review and verify it because it’s expensive and much of their data is illegal.
Also, researchers asking ChatGPT for long lists of random numbers were able to extract its training data from the output (which OpenAI promptly blocked).
It’s training and fine tuning has a lot of specific instructions given to it about what it can and can’t do, and if something sounds like something it shouldn’t try then it will refuse. Spitting out unbiased random numbers is something it’s specifically trained not to do by virtue of being a neural network architecture. Not sure if OpenAI specifically has included an instruction about it being bad at randomness though.
While the model is fed randomness when you prompt it, it doesn’t have raw access to those random numbers and can’t feed it forward. Instead it’s likely to interpret it to give you numbers it sees less often.
I like Javascript… but it is certainly an unholy amalgamation of mismatched parts that, in the end, can get pretty much anything done if you don’t mind 100+ node dependencies.
Vim user here. The only way to exit vim is to pray to the Vim gods and sacrifice your first born, hoping that they’ll cause a cosmic ray to hit the right spot in the memory to flip the right bit that causes it to exit. There are no alternatives.
I am non-serious, I just don’t like vim (or emacs; if I’m editing a text file in a terminal I want nano, or I append manually with pipes as Linus intended).
Most of my systems have X11 and some basic GUI text editor, my server is the exception that proves the rule. There is generally no actual reason to use Vim except liking Vim, or wanting to learn to like Vim.
For those that do like Vim, or want to learn it for historical reasons? Good on you, have fun.
The main reason for using (neo)vim is motions and text objects. Pretty cool to be able to type cxia, ]a, cxia to swap two function parameters in code. Or daf to delete a whole function.
Even just f to jump to a specific character later in the line, or t to jump up to that character are absolutely life changing.
I love love love editing HTML in neovim with the ability to do stuff like dst for “delete surrounding tag” or St<div class=“something”> to surround the current selection with a new tag. I have yet to find another editor that can do stuff like that with just a couple key presses.
These is one of the oldest Linux memes. No, they aren’t serious. I have a hard time believing anyone here doesn’t actually know how to exit vim properly.
This has been said time and time again but fuck Nvidia. Preventing compatibility layers ensures games and programs that need this stuff are extra unreliable, bloated and enshittified.
There really isn’t. For example web browsers can execute assembly now and a good “web developer” (I’d call them a software engineer) will use assembly where appropriate.
With WebUSB (supported in Chrome) and the possibility to build web applications to controls physical devices there’s definitely some web developers who can claim to be proper engineers even in the strict definitions
The classic imagery of someone playing with frontpage back in the day, or screwing around with html in a text editor, sure. But those folks wouldn’t call themselves web developers (there was a phase over 20 years ago where anyone that cobbled together a geocities would declare ‘web developer’ on their resume, but I haven’t seen someone do that in ages).
However, you can get in pretty deep with code running in the browser as javascript and/or wasm. Backend gives them some nested dictionary in json or protobuf and they parse, manipulate, iterate over it, sometimes making some pretty complex visualizations. Basically a ‘web developer’ is nowadays on par with any Game or GUI application developer in terms of what they might be writing. There are a few things left out of direct reach by a browser runtime, but you have access to plenty and the backend abstractions to get something in reach of HTTP are often no easier than the thing being abstracted, it’s just reframed as ‘http’.
programmer_humor
Top
This magazine is from a federated server and may be incomplete. Browse more on the original instance.