|
The doubletalk in this video is epic. Buzzwords and jargon beyond belief. I think it's really funny.
Technical Jargon Overload - YouTube[^]
"The fictional Retro Encabulator device, which uses six hydrocoptic marzel vanes and an ambifacient lunar wane shaft to prevent unwanted side fumbling. "
"inverse reactive current for use in unilateral phase detractors."
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Too funny
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
I hope the inducer is regulated by a trilateral hanging bivalve or the thermoplated phase shifters will be destroyed inside a year.
Real programmers use butterflies
|
|
|
|
|
Only if the phase shifters haven't been optically recoded.
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
So,
I'm slurping data from all over the internet for my NLP research project.
Australian National Corpus[^] (extremely slow)
American National Corpus[^] (expired certificate)
Looks like the British National Corpus[^] doesn't have any problems. For some reason the Brits slapped a copyright and want to charge a licence fee[^] to use their tiny little corpus. 
Google Books n-grams[^] has been taken down.
I believe a very small group of people are maintaining these datasets. The english-corpora.org[^] website has some strange features. The domain name is registered in the name of Google:
[Whois Record for english-corpora.org]
Google LLC
IANA ID: 895
URL: https://domains.google.com
Whois Server: whois.google.com
1,456 days old
But according to IANA 209.90.108.232/29 [^] the IP subnet belongs to Mark Davies[^]. (After poking around a bit I found he is running the site on Windows Server 2016) So it looks like this guy is paying for hosting all that data out of his own pocket. I am very grateful that people like Mark are maintaining these datasets.
I need a bigger super computer.
|
|
|
|
|
Randor wrote: So it looks like this guy is paying for hosting all that data out of his own pocket
Wanna bet?
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
This is the kind of code that will still run in thermostats displays in 100 years after your death.
I woke up to that message on Reddit's ESP32 forum and it made my morning.
Real programmers use butterflies
|
|
|
|
|
An atta-boy negates a lot of oh-sh*ts.
Congrats
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
It seriously does. I get an attaboy every other year or so at work. It's unreal how much that does for my state of mind.
(if you think that's pathetic, you get the point)
Software Zen: delete this;
|
|
|
|
|
That should make your day for the next hundred years...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
But the thermostats wont last so long and display chips and IDE may change from time to time. Are you now on e-paper as my company?
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Not familiar with the codebase, so I can only imagine what prompted the commit titled "grr"  Looks like it had something to do with the RA8875.
|
|
|
|
|
It was a merge conflict, and VS code's interface to handle them is infuriating. It kept staging my changes and I couldn't seem to get it to accept my overrides to the merges. I didn't expect the "grr" commit to actually commit. Keep in mind I had already tried to commit unsuccessfully several times by then.
Real programmers use butterflies
|
|
|
|
|
That explains it  I still think one of my best time investments was learning git on the command line. It seems like every git tool has issues like this.
|
|
|
|
|
I've learned it but it never seems to stick. I always wind up having to google what I need to do.
Real programmers use butterflies
|
|
|
|
|
Fair enough. I was the "git master" for a year on a project so it was my job to resolve any repo issues and a lot of the common stuff ended up sticking for me. I still use git-scm for reference though 
|
|
|
|
|
To me it seems to be every GIT tool and GIT itself.
Obligatory XKCD[^].
|
|
|
|
|
I've been that friend in the hover text That is way too accurate. It really is pretty simple though! Honest!
|
|
|
|
|
Many years ago I made an in depth comparison between GIT and Mercurial. I chose mercurial and have never looked back, it just works.
I keep hearing people at places complain about GIT messing up, while the main complaint about Mercurial is that it isn't GIT. 
Anyway, sooner or later I will have to give in, GIT is winning on pure inertia.
|
|
|
|
|
I'm sticking with Git because of it's "market" saturation. Basically, everyone uses it.
That means that
1. It's not going anywhere
2. Most major IDEs and code editors support it, if badly at times
3. If something *does* go wrong, there's a lot of pressure on Microsoft to fix it due to the size of the userbase
Real programmers use butterflies
|
|
|
|
|
That's it.
Except for point 3 which only applies to Github and still won't explain Office.
|
|
|
|
|
That's fair.
Real programmers use butterflies
|
|
|
|
|
I've done some digging around because I've never heard of Mercurial before. They seem pretty similar to be honest. Many of the common commands are the same and many of the flags for those commands are the same. The big difference I can see at the moment is the branching strategy. Since named branches in Mercurial are permanent, it seems like you could really bloat a repo over time with nonsense unless you're super careful about primarily using bookmarks. But then you lose the multi-head ability of branches which seems like the big feature that makes Mercurial "easy to use" since it let's you ignore what in git would be a FETCH_HEAD merge on pull. I can see where this would also cause issues down the road though - you have to remember to merge eventually.
Overall I'm always of the mindset that if it meets your needs then go for it, seems like a solid DVCS, but personally I think I like the direction git is going. The newer sparse-index and sparse-checkout features are really cool even though at the moment I'm not working on any monolithic repos large enough to feel the benefit.
|
|
|
|
|
Jon McKee wrote: you have to remember to merge eventually.
Default setting is that you can't push without merging first.
It's obviously a different mindset, but if you haven't gotten stuck in the "GIT thinking" it's actually easier.
Remember, branches aren't the same things.
But as you say, the capabilities are very similar.
There's a really good primer on the differences here[^]
|
|
|
|
|
That was a really good read. Highly recommended to anyone scrolling through these comments. I still think git isn't as complex as people make it out to be though. Aside from plumbing commands that the majority of people will never touch, the git commands are just operations on four basic structures - tags, commits, trees, and blobs - across three "copies" of the repo - working directory, index/staging area, and the local repo. And a lot of those commands are just common combinations of simpler commands.
Next time I'm starting a new personal project I might try out Mercurial though. Can't knock it 'til you try it 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
