Absolutely. Additionally, Mercurial is just more accessible in terms of customization. On top of that more than a handful of these shops had heavy Python contingents internally.
I really like how the author approaches programming, and editors from a usability perspective. He is very articulate and did some through research on the history of Lisp editors, recreating the key interaction to illustrate how they worked.
Let me clarify my thinking a bit. For a certain class of problems, Elm is like that as well. But it certainly has limitations - not a huge number of libraries etc.
However, I think that pretty much everything web related is like that - limitations are everywhere, and they’re much tighter than I’d like. For example, every time I needed to add a date picker, it was complicated, no matter the language/framework. But perhaps your widgets library has finally solved it - that would be cool!
So I researched Elm and got a feel for it’s limitations, and then I could apply it (or not) appropriately.
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
If people encouraged you to use native modules, then that was unfortunate.
I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
Might it instead be the other way around: that customization-seeking companies are more likely to choose Mercurial? This could be either because adventurousness promotes both non-Git and customization, or because Mercurial has the better architecture when you need to customize. IIRC the latter is true for both Mozilla and Facebook. Anyway, at my second job we used vanilla Mercurial, and we did fine. It was basically the same as any Git workflow, for that matter.
Huh, well it’s very probable I’m just not aware of all the wild things people do out there with Mercurial. I frankly had no idea there were sub-repo extensions (outside of the core subrepo feature), and I don’t know why anybody would do custom authentication when SSH works everywhere (although I understand people might want to setup ActiveDirectory for Windows-only environments instead, but that’s it). What do you mean by “configuration extensions”? As for MQ, I don’t think it matters for the central repo, no? It should only matter for local workflows?
I suspect my issue might be more in my head (and my unique experience) than in reality. I have contracted with lots of git shops – and a fair number of mercurial ones. Most of the git shops worked very similarly, they differed in master dev versus feature branch dev, mono-repo or multi-repo – but they all felt similar and I could use very minor changes to my workflow to integrate with them, which is great for contracting.
Each mercurial shop has been a wild adventure in unique workflow, and brand new extensions I have never seen or used. One used TWO different sub-repo extensions, another one used THREE configuration extensions! On top of that, most of them had annoying/wonky authentication mechanisms (some hand-rolled). The reason I use those examples (which is only a fraction of what I have seen) is that are all basically non-optional. I needed to use them to be able to work on the project… and of course mq versus non-mq. Never used evolve (yet).
During the “will mercurial or git win?” – I was firmly on the mercurial side because I did work on Windows and git early on was non-function on it. But now when I hear a client is a mercurial shop, I dread it. But, I realize that is probably just my unique experience.
I would assume he’s talking about the kind of abuse you see often on Twitter (anything from randos to sockpuppets to bots to whatever). The original idea was that we’re limited to whatever moderation (or lack thereof) the Twitter HQ decides to do on their network, and on the other hand, various admins of Fediverse instances can do various amounts of moderation, so finding a “good” instance would in theory protect you better from harassment than Twitter. But the reality is that blocking/muting people might be harder on the Fediverse, where it’s harder to track the people behind the accounts, and given that instance admins have little credentials to show for, you could potentially get your data (PMs, etc.) stolen more easily than on Twitter.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.
I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).
I’ve been keeping an eye on IRCCloud – I currently keep a ZNC server running… playing with it has been quite fun and instructive so far, but I would be OK paying 5$/month for someone taking care of it all. I’m waiting for them to open up a bouncer service so we can connect with other clients than their official IRCCloud client… apparently it’s on their roadmap (see bottom).
Yes indeed. For those unfamiliar, here are (from the link) examples of the two docstring styles that Napoleon (a Sphinx extension) parses and renders. PyCharm, too, parses Numpy and Google docstrings and uses the information for tooltips, static analysis, etc.
Google style:
"""Summary line.
Extended description of function.
Args:
arg1 (int): Description of arg1
arg2 (str): Description of arg2
Returns:
bool: Description of return value
"""
return True
NumPy style:
"""Summary line.
Extended description of function.
Parameters
----------
arg1 : int
Description of arg1
arg2 : str
Description of arg2
Returns
-------
bool
Description of return value
"""
return True
No reason has been given.
Was locked automatically by some rules. Unlocked manually by Twitter support team. Could not use my phone number to unlock it right away. Says it’s “not supported”.
I didn’t do anything unusual. Have no idea how to prevent future locking.
Haha, yes, knowing the language certainly makes it easier to stray off the common path and into the woods of in-shop customization :-D
Being a troll is “a way of lowering quality and adding noise”.
Absolutely. Additionally, Mercurial is just more accessible in terms of customization. On top of that more than a handful of these shops had heavy Python contingents internally.
I really like how the author approaches programming, and editors from a usability perspective. He is very articulate and did some through research on the history of Lisp editors, recreating the key interaction to illustrate how they worked.
Sounds like a great development experience!
Let me clarify my thinking a bit. For a certain class of problems, Elm is like that as well. But it certainly has limitations - not a huge number of libraries etc.
However, I think that pretty much everything web related is like that - limitations are everywhere, and they’re much tighter than I’d like. For example, every time I needed to add a date picker, it was complicated, no matter the language/framework. But perhaps your widgets library has finally solved it - that would be cool!
So I researched Elm and got a feel for it’s limitations, and then I could apply it (or not) appropriately.
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
If people encouraged you to use native modules, then that was unfortunate.
I’m not sure I understand the issue with custom elements. Sure, they’re a bit complicated and half baked but it certainly doesn’t require a research lab to use them (in fact, I’ve just implemented one now).
I would agree, however, that the Elm developers have a bit of a hardline approach to backward compatibility. Perhaps there is a misunderstanding around the state of Elm - ie whether it’s still an experiment that can break compatibility or a stable system that shouldn’t.
I’m not sure how I feel about backward compatibility. As a user, it’s very convenient. As a developer, it’s so easy to drown in the resulting complexity.
“Dangerous” compared to what? Force how?
Low-effort regurgitation of screencaps is not some big act of rebellion, it is just a way of lowering quality and adding noise.
If we wanted to read fiction we could go enjoy the sister Lobster site devoted to that activity.
Might it instead be the other way around: that customization-seeking companies are more likely to choose Mercurial? This could be either because adventurousness promotes both non-Git and customization, or because Mercurial has the better architecture when you need to customize. IIRC the latter is true for both Mozilla and Facebook. Anyway, at my second job we used vanilla Mercurial, and we did fine. It was basically the same as any Git workflow, for that matter.
Huh, well it’s very probable I’m just not aware of all the wild things people do out there with Mercurial. I frankly had no idea there were sub-repo extensions (outside of the core subrepo feature), and I don’t know why anybody would do custom authentication when SSH works everywhere (although I understand people might want to setup ActiveDirectory for Windows-only environments instead, but that’s it). What do you mean by “configuration extensions”? As for MQ, I don’t think it matters for the central repo, no? It should only matter for local workflows?
I suspect my issue might be more in my head (and my unique experience) than in reality. I have contracted with lots of git shops – and a fair number of mercurial ones. Most of the git shops worked very similarly, they differed in master dev versus feature branch dev, mono-repo or multi-repo – but they all felt similar and I could use very minor changes to my workflow to integrate with them, which is great for contracting.
Each mercurial shop has been a wild adventure in unique workflow, and brand new extensions I have never seen or used. One used TWO different sub-repo extensions, another one used THREE configuration extensions! On top of that, most of them had annoying/wonky authentication mechanisms (some hand-rolled). The reason I use those examples (which is only a fraction of what I have seen) is that are all basically non-optional. I needed to use them to be able to work on the project… and of course mq versus non-mq. Never used evolve (yet).
During the “will mercurial or git win?” – I was firmly on the mercurial side because I did work on Windows and git early on was non-function on it. But now when I hear a client is a mercurial shop, I dread it. But, I realize that is probably just my unique experience.
I would assume he’s talking about the kind of abuse you see often on Twitter (anything from randos to sockpuppets to bots to whatever). The original idea was that we’re limited to whatever moderation (or lack thereof) the Twitter HQ decides to do on their network, and on the other hand, various admins of Fediverse instances can do various amounts of moderation, so finding a “good” instance would in theory protect you better from harassment than Twitter. But the reality is that blocking/muting people might be harder on the Fediverse, where it’s harder to track the people behind the accounts, and given that instance admins have little credentials to show for, you could potentially get your data (PMs, etc.) stolen more easily than on Twitter.
Thing is, FUSE is slower, buggy (I’ve had kernel panics) and less flexible. A native way to track file system operations in a lossless manner would be really nice to have on linux.
My bad! :-)
https://medium.com/@farsi_mehdi/procs-and-lambdas-46433b93080d
I did this at the beginning but quickly switched over to ZNC because of bugs like that, the inability to have per-client history rollback, and other little details… I still use Weechat half the time on the client side though :) (I also use Textual on macOS, and Palaver on iOS).
I’ve been keeping an eye on IRCCloud – I currently keep a ZNC server running… playing with it has been quite fun and instructive so far, but I would be OK paying 5$/month for someone taking care of it all. I’m waiting for them to open up a bouncer service so we can connect with other clients than their official IRCCloud client… apparently it’s on their roadmap (see bottom).
Please use the
releaasetag for this, since the linked article has no information about unit, practices or webshit.Also, this is advertising and a newsletter signup even if it is for content that’s cool.
Which article?
Yes indeed. For those unfamiliar, here are (from the link) examples of the two docstring styles that Napoleon (a Sphinx extension) parses and renders. PyCharm, too, parses Numpy and Google docstrings and uses the information for tooltips, static analysis, etc.
Google style:
NumPy style:
Thanks for subscribing! :)
No reason has been given. Was locked automatically by some rules. Unlocked manually by Twitter support team. Could not use my phone number to unlock it right away. Says it’s “not supported”.
I didn’t do anything unusual. Have no idea how to prevent future locking.