- nocman parentUm, please let your comment be sarcastic. It is ... right?
- > sed is not "stream editor" as it says above, it's "stream ed"
Well, according to the man page, it is indeed "stream editor":
https://man.cat-v.org/unix_8th/1/sed
I was already aware of its relation to 'ed' (having had to actually use 'ed' in ancient times). However that doesn't change the fact that it does stand for "stream editor".
After reading your post, I thought "That doesn't seem right, I remember it specifically being referred to as 'stream editor'", so I went looking.
- > There was strong cultural pressure to be able to write perl in as few bytes as possible
Hard disagree. Many Perl programmers enjoyed engaging in code golf (always just for fun, in my experience), but in my nearly 30 years of programming Perl, I never encountered anything that I would call pressure to do so -- not from anyone.
- I don't think in this case that most people who know what Arduino is would be at all mislead by the title. Being "dead" doesn't have to mean that a company ceases to exist. There are plenty of what I would call "dead" companies that still make money every year. "Dead" can be used figuratively. In this case, meaning that though the company continues to exist, the reason for which many people bought their products is now gone.
- "With traditional solutions (such as OpenVPN / IPSec) starting to run out of steam" -- and then zero explanation or evidence of how that is true.
I can see an argument for IPSec. I haven't used that for many years. However, I see zero evidence that OpenVPN is "running out of steam" in any way shape or form.
I would be interested to know the reasoning behind this. Hopefully the sentiment isn't "this is over five years old so something newer must automatically be better". Pardon me if I am being too cynical, but I've just seen way too much of that recently.
- > for me, everything git is a pain point
Yeah, I was looking for something (or "things") specific. An "I hate everything about it" explanation doesn't really compel me to try out the alternative.
> "megamerges" are one such example. ive shared many links, here and in other posts
I read through one megamerge link you shared ( https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... ). So the argument seems to be (forgive me if I'm reading this wrong), if you have multiple versions of a single set of source files that all have differing changes, for you JuJutsu makes it easier (easier then git, that is) to merge them into the final commit you want to end up with. Is that correct?
Just trying to make sure I understand. Honestly, after reading that article I am still not feeling the need to try Jujustu out. I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!".
- > In git, if you get a conflict, you feel like you have to resolve it now.
I guess I view that as a positive rather than a negative. I'm not saying that dealing with merge conflicts is a picnic -- it isn't. I just find it difficult to believe that ignoring them and resolving them later will improve the situation in the long run.
- Is there a particular pain point (or set of pain points) that you have using git which is removed when you use Jujutsu?
I am interested to know, because there seem to be a small number of people who really seem to like it, and up to this point I haven't been able to understand what it is that they are all so excited about.
- > Some people just enjoy being contrarian.
And some people just happen to disagree - doesn't automatically mean they just like "being contrarian". I took the "Yup..." to mean "this is what I was expecting, because it agrees with what I have seen before on this topic".
> I always enjoy how on jj articles, 90% of commenters tried it and switched, 10% never bothered to try it, and 0% tried it but decided not to switch.
And some unknown quantity of readers don't see anything compelling enough to either try it and/or comment on it after they have (or have not) tried it.
- I'm not sure if you are being serious about not understanding "the whole centering a div meme". Your example handles a trivial case, but does not address the whole of the problem.
As others have pointed out, vertical centering is often the problem being discussed (although difficulties with horizontal centering do happen). Anyone I know that has written any non-trivial web application has run into the situation where they spent way more time than they thought they should have to getting some element in a web application centered on the page the way they wanted it to be.
This article is a good example of the complexity, I think:
https://css-tricks.com/centering-css-complete-guide/
The author makes a decision tree, which illustrates the complexity fairly well, and then there's a conversation in the comments between the author and a reader about whether parts of the decision tree are correct.
CSS is extremely complicated. It's easy to get lost in the complexity, and it can be very frustrating when you know how you want something to look, but can't quite figure out how to get it to happen.
That's why the meme is so popular. LOTS of people who deal with CSS can relate.
- > presuming to be able to identify "the best programmers"
He was identifying the best programmers he knows (as is obvious from the title). I don't think it is unreasonable at all for even a semi-technical person to be able to do that.
Also, it is highly likely that the author never expected their article to receive a high volume of web traffic, and allocated resources to it with that assumption. That doesn't say a thing about their technical abilities. You could be the best programmer in the world and make an incorrect assumption like that.
- > I started using git around 2007 or so because that company I worked for at the time used ClearCase, without a doubt the most painful version manager I have ever used
Ah, ClearCase! The biggest pain was in your wallet! I saw the prices my company paid per-seat for that privilege -- yikes!
- > Git was always worse than Mercurial.
hard disagree. Git was always way better than Mercurial.
> It won because of GitHub.
I and most of the developers I have worked with over the years all used git for many years before ever even trying GitHub. GitHub obviously has helped adoption, but I'm not convinced that git would not have won even if GitHub had never existed.
- > Git is for hobby side projects. Perforce and Sapling are for adult projects.
The numbers I've seen say git has about 87-93% of the version control market share. That's just one of many reasons I think it is safe to say most professional developers disagree with you. I can understand someone prefering Perforce for their workflow (and yes, I have used it before). But saying Git is only "for hobby side projects" is just ridiculous. It has obviously proven its value for professional development work, even if it doesn't fit your personal taste.
- The ones I did this from were "Compute!" and "Compute's Gazette! (for Commodore 64 and VIC-20)". They were all octal numbers, if I remember correctly, and the last number in each row was a checksum. I also paid my sister to type in some of them in for me. A lot of them were games, but there were also some very useful programs in there. I spent so many late nights typing away on that 8-bit machine. It was a cool time to be a kid who was interested in computers.
- In fairness the person you were responding to was referring to their own personal experience. They certainly are not the first person to conclude that doing non-trivial concurrent programming is too difficult for them. I agree that it is achievable with an appropriate level of care and experience, but I know there are many very smart people that conclude that multithreaded programming in C++ is too difficult for their taste.
Even Rich Hickey, when discussing concurrency in Java/C#/C++ said "I am tired of trying to get right, because it is simply far too difficult."
> In particular, talk about shared state, how we do it today, how you do it in C#, Java, or C++, what happens when we get into a multi-threaded context, and specifically what are some of the current solutions for that in those spaces. Locking, in particular. That is something I have done a lot of, over a long period of time, and I am tired of trying to get right, because it is simply far too difficult.
( https://github.com/matthiasn/talk-transcripts/blob/master/Hi... )
- Yeah, the main references I found to IVR systems and REXX were from IBM articles discussing IVR, and some open-source Asterisk-based systems using ooRexx that appear to have been created as an open-source alternative to IBM OS/2 IVR solutions that used REXX.
OS/2 is the primary environment where I had experience reading and writing REXX a long time ago. I was also aware of it being used in IBM mainframe systems, but I had no direct experience there.
- > The Sealed-Bid auction should generate a price that is greater than or equal to the English Open Cry in all situations.
Not necessarily. In many sealed-bid auctions, bidders hope to win with a lower bid (often much lower) than they would if they were bidding against others in the same room. This is especially true if you have no idea whether anyone else is bidding on the item at all. I have placed very low bids on items in sealed-bid auctions for things I had no immediate need for, but would happily pay for if the cost was very low (and I have won many such items, sometimes because no one else even bid on them).
- Perl's reputation for this is entirely unfair, in my opinion.
I just opened up a random reasonably-large Perl program that I last touched over three years ago, browsed through the source, and I have absolutely no trouble telling what it does.
I don't think Perl code is any more difficult to revisit than code in most other programming languages are. I think the difficulty mostly rests with how proficient the developer is in the language, and how long it has been since they wrote any code in that language. If you are really rusty with the programming language, or you never really had a high level of proficiency in it in the first place, you are going to have a hard time revisiting the code no matter what language it is.
Of course, it will be harder if the code is not your own. Also, it depends a great deal on how well the code was written. There's plenty of garbage code out there, in any language you might use. And if it was garbage to begin with, it won't get any better with age.