I went to college starting 2007 (right when CUDA was released) and recall a few things about python that made it attractive in both the comp sci and math departments at my school.
- python integrated well with lesson plans instructors had
- python integrated well with the software math departments were using (like MATLAB)
- python had a very easy to use interpreter environment that worked well on linux, mac, and windows
- python had (for the era) a massive standard library, making it way easier to consume and process
common data file formats like XML or CSV without having to install any extensions
(installing extensions usually required admin permissions and... very few at school had those for very good reasons)
- exposing c/fortran libraries into python was pretty straightforward to do and was relatively stable compared to alternatives.
Around 2007, the main competitors in the scripting space had a lot of issues:
- tcl - somewhat popular for embedding but didn't really have a standalone interpreter that made it easy to interact
with and the syntax didn't really look like C, and really not much of a library to work with
- lua - similar to tcl, popular for embedding but didn't have a popular standalone runtime and interpreter.
syntax was closer to C though. didn't have much of a library to work with
- ruby - had a runtime for experimenting but a less stable API for integrating, plus the language was pretty
different from C. the library was large but had a larger reliance on installing extensions than python at the time.
- perl - both unstable and had a horrible reputation by this point as a standalone language that outside of some obtuse
systems scripting, most people didn't want to touch this with a 12-foot pole. standard library was small and relied a lot on extensions.
- php - similarly unstable (at the time... i think 5.3 had just come out) and had a horrible reputation... also not even
sure it had a runtime that worked outside of an apache/nginx context... exposing a c library to PHP at this time was pretty
straightforward though. relied very heavily on extensions at this point.
- javascript - node.js hadn't come out at this point... so the idea of running javascript outside of a browser window wasn't really a thing yet.
If one were looking to expose CUDA to programmers who didn't want to work in C during this era, I'd argue that python was just the best option at the time.
I believe that led to a first-mover advantage that has held over time.
The usability without extensions part is underrated. Whether I'm a beginner in school or a pro trying to hammer out a quick script, I would prefer the thing that doesn't make me jump through hoops to deal with CSV JSON XML etc. Far more important than the language syntax or other things.
And the little scripts I write at work tend to grow and then turn into full-fledged services in a shorter period of time than it would've taken to set up the C++ or whatever boilerplate.
Perl6 is no Perl it has been renamed to Raku. The rest of the Perl5 environment it's ultra-compatible with previous releases.
Albeit compiling PDL it's rough case.
You look like never touched Perl seriously, Raku it's still a hard deviation.
No one used Perl6 on real life environments. It's the Duke Nukem Forever of the programming languages.
Using Perl6 as an argument on Perl5 it's like bashing the simple and clean ANSI C giving C++ as the example and its the crazy redundant features as a rant.
We're talking about the choice of Python for ML when CUDA came along, nearly 20 years ago. Upthread, alaties said:
> Around 2007, the main competitors in the scripting space had a lot of issues: [...]
> Perl [...] unstable
RadiozRadios replied:
> Huh? Please elaborate.
I did.
In 2007, Perl 6 was not Raku, it was intended to be the next major version of Perl. But it had been in development for ~7 years already, couldn't be relied on or predicted, and had become a bit of a joke. Since Perl 6 was still supposed to be the future of Perl, in 2007 Perl very much seemed unstable and unsuitable as a foundation for ML research.
I agree on Perl's choice. But Perl5 was granted as an stable platform, kinda like AWK, pretty much unlike Perl6, which wasn't the future of the current Perl5 at all, except for the hype.
Would cast iron pots and pans count as thick-bottomed in this case?
I usually use these with electric stoves since they retain heat pretty well. They take a while to warm up though, so there's both time and energy lost in that warming process.
The best vessel is a flat bottomed one with at-least quarter inch thick bottom.
Cast Iron ones will do too.
If you have to cook something to simmer and hold heat for long, best use thick bottomed ones.
What could be done to mitigate the slow heating issue is to use a small amount of water initially, on high settings, allowing it to boil. Then you can add your contents, reduce the power setting and allow it to simmer.
What many dont know is that you can keep a cast iron or steel plate between the vessel and the stove, of a suitable thickness, that converts the induction stove to a "heater" stove (the plate gets heated through induction, but the vessel only sees the heat). However, a word of caution. If the plate is of a very large size, it will have un-even heating and may warp. Best size is one that is slightly smaller than the circular marker on the stove.
I primarily use cast iron for cooking, and it does help with the hysteresis, but I still have a problem with the bottom of the pan being way too hot and tending to burn food.
Yeah... Bird configurations are a little rough to learn. The examples they have on the website are pretty lacking. Their mailing list is usually helpful though.
Quagga is usually easier to find examples for since it's modeled after Cisco switch syntax for configuration (same basic syntax of arista switches).
Both of these really suck to learn as a programmer since you're usually coming into these without much of a network engineering background. I remember struggling a lot with both of these config syntaxes until a network engineer took me under his wing and taught me basics, principles, the engineering challenges of packet switching at scale, etc.
It should be noted that an EXPIREAT triggers a deletion if the timestamp being set is in the past and could lead to an increase in memory and disk pressure during script execution. Worth checking if the behavior there differs in any meaningful way since y'all made the change. EXPIRE usually just marks a key and relies on either subsequent operations to the same key or garbage collection to actually excise the entry and do the subsequent bookkeeping, I believe.
It's been a while since I had to deal with this kind of problem though, so please tell me if things are different now.
I'm kind of shocked no one brought up protobufs yet. protobuf libraries are available in pretty much all mainstream languages and the textproto format is pretty mature.
It's albeit clunkier and less freeform than YAML. And if you ever only plan on using rust the proposed solution here is probably cleaner.
Having portability over multiple languages maintained by large organizations can be useful in some cases though.
Interestingly, I've found that studying other engineering disciplines outside of software engineering to be best. The best explanations and modeling frameworks for concurrency I learned were from network engineering books and a couple hardware design classes I took.
Re: principles around performance analysis and diagnostics, Brendan Gregg is a name you should look up. His book on systems performance is a tremendous resource in both principles and methodology. Even though it's not focused on coding specifically, the same principles apply.
Best option is to force encryption on all bittorrent traffic. Most clients support full protocol encryption (PE or MSE) these days, so forcing it shouldn't be an issue. For libtorrent, you'd set in_enc_policy and out_enc_policy to pe_forced.
Whether a particular client exposes this or not depends.
In the case of this project... looks like upstream github.com/anacrolix/torrent does support encrypted connections. Not clear how to force it to use _only_ encrypted connections though.
I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.
If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.
C++ these days still supports all the syntax and programming style of C++ in the 70s. You probably mean "you can program in a hygienic and safe way in C++", which is true, but also is not necessarily a feature of the language but of the programmer (just a few years ago I interacted with some theoretically senior C++ programmers who claimed mixing raw pointers with smart pointers is fine because they're senior and know what they're doing).
Ask developers to safely define a string constant that is accessible outside of that translation unit. Now do it without C++17, which many companies aren't using yet.
Things have gotten a lot better, but even these incredibly basic needs can be really tricky.
These kinds of cameras produce pretty high volumes of data, since it's picture + 3D dot cloud per frame. My guess would be even 1G over wifi wouldn't be enough throughput without some compression engine in place.
I believe that led to a first-mover advantage that has held over time.