I once worked under someone who felt strongly about us importing modules instead of classes. So instead of
from sklearn.feature_extraction.text import TfidfVectorizer
tfidf = TfidfVectorizer()
we were told to change it to
from sklearn.feature_extraction import text
tfidf = text.TfidfVectorizer()
to be compliant. Guess what variable name everyone used to store document text in every file.
Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoid common names for packages then this whole class of issue goes away.
> Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoided common names for packages then there would not have been an issue.
If your solutions depends on others to "do the right thing", it often isn't a viable solution.
However, how you import something in your own files, is something you most likely control.
Having a global style policy (for imports) doesn't seem like relying on others to "do the right thing". It's just style and is completely arbitrary.
Someone probably encountered a problem with having a mishmash of ways people do imports and thus began the policy. It's the type of policy where someone heaved a great big sigh and said, "this is why we can't have nice things."
I was specifically referring to the "Now I'm realizing if we all avoided common names for packages then there would not have been an issue" part as relying on others to do the right thing.
Having a internal policy about how to import something wouldn't be relying on others to do the right thing.
This is one of the benefits of having all your libraries/modules in a monolithic repo: You can refactor the names of everything pretty easily. It'd be a BIG commit but it's still a trivial task to rename something like `text` to `textual` or `text_anal` everywhere it's being used.
I've done it before. It's the type of thing where you'll find out immediately if you screwed up somewhere but modern IDEs usually do a pretty good job at such things (the free version of PyCharm will do it real fast and then you never have to open it again if it's not your thing).
> Calling this site "Dotnom" makes sense because after visiting it, the only thing I'm left dotting is the 'i' in 'unimpressive.'
Most of the rest of the roast addresses atypical design choices, which is exactly what I'd expect to be focused on in a real roast. I really enjoyed this!
> One employee said it was rumored that close to 100 employees in Cloud's GTM group in the Asia-Pacific region were cut. A Google spokesperson said that number was lower.
For anyone turned off by the title, here's the first sentence:
> Disclaimer: There is no actual profit. That was just one of those clickbaity things everybody seems to like so much these days. Also, it’s not really fun. Alright, on with the show!
In case you didn’t recognize the trope: It’s a reference to the seminal article ‘Smashing the stack for fun and profit’ by Aleph One. Published in Phrack #49, 1996. IIUC that was the article that introduced the concept of buffer overflow exploits to a wider audience. People have been writing ‘X for fun and profit’ headlines ever since.
Also, i think this idiom sound nice, and add disambiguation to the sentence ("Root your docker host" can mean something totally different than the OP title)
On dot matrix and impact (like daisywheel) printers, there were sprockets along the side edges of the paper so that the tractor part of the printer could advance the paper after a linefeed.
It's sometimes called 'listing paper', as it was commonly used to print out listings of your code :
Also known as "Continuous Stationery" (one of my Father's customers companies was even called that) because each page was joined via a perforated line or "fanfold" as it was folded into the box with alternating left-right folds along the perforation just as a paper fan is folded.
Often the holes for the tractor feed were also separated from the main part of the page by a perforation so that one could tear it off to leave a more-or-less pristine letter (or A4 over here) page of content.
Fiddling with the left-over narrow strips of hole-punched edging paper was one of those universal habits that you don't even notice until long after it's gone.
(Edit: _a_ I just realised I replied to the wrong parent post and _b_ now I'm wondering if you're somebody I know!)
That's hilarious! When I mentioned the joy of messing with those strips of holes from the paper I was thinking of a specific occasion in a very dull lecture (business studies?) when I built a small paper boat out of them and you and Phil (I think) sitting in the row behind me said it was the only interesting part...
As Pratchett said, "We've all passed a lot of water since those days..." :D
Epson LX300 was on my wish list for a long time. I didn't have the money at the time, then inkjet happened and the matrix printers became extremely expensive here.
I got what you described by learning Common Lisp just a few months ago. Do you think learning Clojure would get me something in addition to that or is it roughly the same?
> Do you think learning Clojure would get me something in addition to that
For me, the biggest benefit is that it's hosted. Learning only Clojure, I can easily today write for JVM, .NET, JavaScript, Flutter, or shell scripts. Even when I need to write Lua, I'd usually pick Fennel. It's not Clojure but feels very similar. There are libs that can give you Python or R interop from Clojure. There are projects to target Golang, Rust or Erlang. Jank is a super interesting, experimental implementation of Clojure that runs on LLVM, I'm very excited about it. Do you want to become a true polyglot programmer? You only need to learn Clojure.
I can't really say. I know you can (for example) use LispWorks to write CL for mobile, targeting both - Android and iOS, but I think there would be greater friction to keep it cross-platform, each platform's nuances would have to be handled differently, it's not going to be very unified codebase (I think).
I think Clojure leans into immutability a lot, and that leads to more interesting APIs and norms that are valuable. CL has always felt a bit more.... "running on a machine" that I feel has less of a place in an era where everyone and their dog has functional programming essentials built in.
Clojure is interesting, but some Clojure APIs (stuff like Spectre) is "I want this everywhere now" stuff.
Clojure also teaches you functional programming, where-as CL only teaches you the LISP beauty. Clojure teaches you both Lisp and Fp. So the FP part should still be worth it even though you got the Lisp part from CL.
Clojure has immutability built into the language and the core data structures are all persistent so that you can get sufficiently efficient partial updates while still preserving a pure FP style.
Furthermore, the data structures in clojure also have interfaces that make it easier to swap out which data structure you're using while still keeping whatever map/filter/reduce algorithm implementation you're sending it through.
Common lisp, on the other hand, has setf. Which more or lets you mutate anything. You certainly can code in an FP style in common lisp, but it doesn't restrict you in any meaningful way. Not a problem if you control the entire codebase, but when gluing components together this can be a source of friction.
FP in CL is kind of optional, and it's also more in the sense that you can pass functions as arguments or return functions, meaning FP == First Class Functions.
But in Clojure, FP is kind of mandatory, there's no OO for example, and it's more than just first-class functions, it's also immutability.
Depends on your style of programming CL. Clojure is immutable by default with a heavy emphasis on concurrency and strong ties to the JVM as its host environment. The differences you’ll find mostly lie in those areas.
IMO, Clojure is superficially/syntactically much more elegant and beautiful than Common Lisp or Scheme. I find this really helps you focus on what matters most.
Clojure uses immutable lists, vectors, hashmaps, and sets. Also it has syntax sugar such as [1 2 3] for vectors, {"Jan" 31 "Feb" 28} for hashmaps, #{1 2 3} for sets, and much more. Also it has multimethods which are even more generic than CLOS.
Would you be willing to make a way that lets users try it without making an account? Or at the very least, make an account with an email address? Right now, I can't find a way to do anything without logging in with a Google account, which I prefer not to do.
For now I prefer to just stick to Google Authentication as that is really secure and avoids me the "pain" of having to deal with password (which I value a lot).
This was one of my favorite "word of the day" entries, a word every speaker tries to work into their speech, at Toastmasters. The person who introduced it gave the two definitions and then basically said "it's the only word I know that means its opposite" or something to that effect. It got liberal use in every speech, including mine, and I still don't feel comfortable using it correctly.
> Cleave is often cited as the go-to contronym: it can refer to splitting something apart and to uniting two things
Weird, I cannot remember ever seeing "cleave" used to mean "uniting two things".
"Inflammable" is my go-to example of a word that shouldn't exist in the English language. Causes too much confusion. I always use "flammable" and "nonflammable".
Yeah, never seen that usage of "cleave". I would have expected that sentence written with a different word: "People in the remote mountain villages still cling to their old traditions."
Ha, you make some good points and I would be ok with those words. But just because the root word (inflame) and some of its derived words are useful, that doesn't mean that we need to allow all possible prefix and suffix derivations of that root word.
Wow. You really want some arbiter of which words are "allowed" or not? That sounds like some real Ministry of Truth type shit. It seems especially weird on a tech site, when tech jargon has historically been rich with wordplay and word construction.
That one's fun, because they don't really mean the same. It's just that there usually is no functional difference between the meanings.
"to inflame" is to set something on fire. "to flame" is to be on fire. So something that's inflammable can be set on fire, something that's flammable can burn.
I would have said the same thing as you, but it now occurs to me that something that is already on fire must be flammable but it is hardly inflammable since you couldn't set it on fire again (without first putting it out at least).
You could also argue that some things, like most metal powders, are barely inflammable (very hard to light) but are very flammable (once they do burn they burn really well and are hard to put out)
The way it's used on warning labels, "inflammable" means it can combust without an obvious ignition. "Flammable" needs to be set on fire from an external source.
Until this article, I always blamed this on the decision to blindly import modules instead of... well... whatever makes sense. Now I'm realizing if we all avoid common names for packages then this whole class of issue goes away.