Hmm, Google’s style + napoleon extension does seem quite good. I wonder if I should update my style guide. I suggested that you should just bite the bullet and use Sphinx style there due to the doc auto-gen benefits, but seems like this is best of both worlds.
You can buy older cars that are in good shape. The one I drive has no tracking devices. It’s pretty good on gas. Maintenance has been a few hundred this year. (Shrugs)
Is there any evidence your tweets or Lobsters submissions have changed security or ethical practices of a major company?
If not, then that’s either not what you’re doing here or you should be bringing that content to Tesla’s or investors’ attention via mediums they look at. It’s just noise on Lobsters.
In Norway’s case, the reason is probably their gigantic sovereign wealth fund. Income from foreign investments held by nationals is included in GNI (as it’s income flowing in to the country) but not included in GDP (because it’s not economic activity that takes place in the country itself).
Whenever I read posts like this, I find myself wishing for more specifics about why these changes were intractable for the author. In this case, the author is clearly unhappy about the ability to compile features that include a direct JS implementation, but the post says nothing about what problem that was actually solving in practice. It’s only in the comments that you find out the author was using a direct JavaScript implementation to avoid having to write JSON dcoders. His comment on decoders/encodes is that:
For us encoders and decoders are an intractable solution which creates at least hundreds of lines of redundant/difficult code to maintain.
I’d really like some more insight into that. Personally, I like Elm’s encode/decode strategy for dealing with JSON, and while they can take a while to write by hand initially, I’ve never found them particularly difficult to maintain. I’m not going to claim that my experience there is definitive, but I’d really like to understand what it is about their data model that makes decoders and encoders hard for them to maintain. Or maybe it’s just a matter of preference and they just don’t like the way decoders work? As it is, I don’t have a way to translate their experience into something I can think about in terms of how I evaluate technical solutions and the problems I have to solve.
“if the GNI is much higher than the GDP this can mean that the country receives large amounts of foreign aid”
The lone country in their accompanying graph where this inequality holds is Norway. I find it hard to believe that Norway is the recipient of any foreign aid…
Why do Medium posts about front-end development always make it seem like such a soap opera? The actual people I know who are into front-end development are all reasonable smart people.
I think there must just be some toxic mutual appreciation subsubculture of front-end “engineers” who like to blog drama.
The actual content of this post when you strip out all of the “I’ll support my French bros” and expletives is minuscule and entirely unoriginal.
Yeah, I agree that the main question is around the state of Elm. If the message is that Elm isn’t finished, and don’t invest into it unless you’re prepared to invest time into keeping up, that’s perfectly fine. However, if people are being sold on a production ready language that just works there appears to be a bit of a disconnect there.
It’s obviously important to get things right up front, and if something turns out not to work well it’s better to change it before people get attached to it. On the other hand, if you’re a user of a platform then stability is really important. You’re trying to deliver a solution to your customers, and any breaking changes can become a serious cost to your business.
I also think it is important to be pragmatic when it comes to API design. The language should guide you to do things the intended way, but it also needs to accommodate you when you have to do something different. Interop is incredibly important for a young language that’s leveraging a large existing ecosystem, and removing the ability for people to use native modules in their own projects without an alternative is a bit bewildering to me.
I use Mercurial at work. My company uses Git, but I use Mercurial and clone, push, and pull transparently thanks to hg-git. I’ve noticed I am generally more aware than my Git-using colleagues of recent changes to the repo, because I’ve got a pre-pull hook set up to run hg incoming (with a tweak to avoid double network talk).
It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl.
We fundamentally disagree on this point (and the value of the noisy new users), and I don’t think either of us is going to convince the other. So, I think this is a classic case of agree to disagree.
I’m pretty confident I wouldn’t change my position on this if I wasn’t in agreement with the core team’s choices. I might switch to PureScript or ReasonML, if I think the trade-offs are worth it, but I can’t see myself continuing to complain/vent after the decision has been made. I think appropriate user input is “I have this specific case, here’s what the code look like, here’s the specific challenge with any suggested alternative” If the core team decides to go another way after seeing their use cases, it’s clear we don’t have the same perspective on the trade-offs for those decisions. I can live with that. I don’t expect everybody to share my opinion on every single technical decision.
As an example, I use Clojure extensively at work, and I very much disagree with Rich Hickey’s opinions about type systems, but it’s pretty clear he’s thought through his position and random folks on the internet screaming differently isn’t going to change it, it’ll just make his job more difficult. I can’t imagine ever wanting to do that to someone.
sometimes the only way to really realize the mistake is the hear the howls of your users
It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl. They can usually speak pretty clearly about how decisions impact their work and are able to move on when it’s clear there’s a fundamental difference in goals.
According to https://www.mercurial-scm.org/wiki/UsingExtensions – there are at least 6 sub-repo extensions. And, yes, ActiveDirectory logins, other SSO variations and then on top of those multiple ACL layers.
As for MQ – absolutely you can avoid it with others tools that can produce the same sort of history… rebase, graft, strip, etc. The issue being if all the “how we work” docs are written in MQ style – it is a bit of mental gymnastics to convert over.
Hmm, Google’s style + napoleon extension does seem quite good. I wonder if I should update my style guide. I suggested that you should just bite the bullet and use Sphinx style there due to the doc auto-gen benefits, but seems like this is best of both worlds.
Got it. Will fix. Thanks!
Who are these people? How do you get yourself on this list? Do you ask your friend to contribute you?
Are these people famous for some reason? How did this list come about in the first place?
You can buy older cars that are in good shape. The one I drive has no tracking devices. It’s pretty good on gas. Maintenance has been a few hundred this year. (Shrugs)
Is there any evidence your tweets or Lobsters submissions have changed security or ethical practices of a major company?
If not, then that’s either not what you’re doing here or you should be bringing that content to Tesla’s or investors’ attention via mediums they look at. It’s just noise on Lobsters.
Lacking off planet travel options, …
suggested tag: wrong
In Norway’s case, the reason is probably their gigantic sovereign wealth fund. Income from foreign investments held by nationals is included in GNI (as it’s income flowing in to the country) but not included in GDP (because it’s not economic activity that takes place in the country itself).
Which is why several people are asking you to stop it.
Whenever I read posts like this, I find myself wishing for more specifics about why these changes were intractable for the author. In this case, the author is clearly unhappy about the ability to compile features that include a direct JS implementation, but the post says nothing about what problem that was actually solving in practice. It’s only in the comments that you find out the author was using a direct JavaScript implementation to avoid having to write JSON dcoders. His comment on decoders/encodes is that:
I’d really like some more insight into that. Personally, I like Elm’s encode/decode strategy for dealing with JSON, and while they can take a while to write by hand initially, I’ve never found them particularly difficult to maintain. I’m not going to claim that my experience there is definitive, but I’d really like to understand what it is about their data model that makes decoders and encoders hard for them to maintain. Or maybe it’s just a matter of preference and they just don’t like the way decoders work? As it is, I don’t have a way to translate their experience into something I can think about in terms of how I evaluate technical solutions and the problems I have to solve.
“if the GNI is much higher than the GDP this can mean that the country receives large amounts of foreign aid”
The lone country in their accompanying graph where this inequality holds is Norway. I find it hard to believe that Norway is the recipient of any foreign aid…
Haha but that’s fine, I don’t think anybody besides myself are using them :)
you… you are part of the problem! runs scared hehe
Why do Medium posts about front-end development always make it seem like such a soap opera? The actual people I know who are into front-end development are all reasonable smart people.
I think there must just be some toxic mutual appreciation subsubculture of front-end “engineers” who like to blog drama.
The actual content of this post when you strip out all of the “I’ll support my French bros” and expletives is minuscule and entirely unoriginal.
Ah I see. And yeah I never really scrolled down past the non-core extensions :) (The only non-core extensions I have are a couple I wrote myself…)
Yeah, I agree that the main question is around the state of Elm. If the message is that Elm isn’t finished, and don’t invest into it unless you’re prepared to invest time into keeping up, that’s perfectly fine. However, if people are being sold on a production ready language that just works there appears to be a bit of a disconnect there.
It’s obviously important to get things right up front, and if something turns out not to work well it’s better to change it before people get attached to it. On the other hand, if you’re a user of a platform then stability is really important. You’re trying to deliver a solution to your customers, and any breaking changes can become a serious cost to your business.
I also think it is important to be pragmatic when it comes to API design. The language should guide you to do things the intended way, but it also needs to accommodate you when you have to do something different. Interop is incredibly important for a young language that’s leveraging a large existing ecosystem, and removing the ability for people to use native modules in their own projects without an alternative is a bit bewildering to me.
I use Mercurial at work. My company uses Git, but I use Mercurial and clone, push, and pull transparently thanks to hg-git. I’ve noticed I am generally more aware than my Git-using colleagues of recent changes to the repo, because I’ve got a
pre-pullhook set up to runhg incoming(with a tweak to avoid double network talk).We fundamentally disagree on this point (and the value of the noisy new users), and I don’t think either of us is going to convince the other. So, I think this is a classic case of agree to disagree.
I’m pretty confident I wouldn’t change my position on this if I wasn’t in agreement with the core team’s choices. I might switch to PureScript or ReasonML, if I think the trade-offs are worth it, but I can’t see myself continuing to complain/vent after the decision has been made. I think appropriate user input is “I have this specific case, here’s what the code look like, here’s the specific challenge with any suggested alternative” If the core team decides to go another way after seeing their use cases, it’s clear we don’t have the same perspective on the trade-offs for those decisions. I can live with that. I don’t expect everybody to share my opinion on every single technical decision.
As an example, I use Clojure extensively at work, and I very much disagree with Rich Hickey’s opinions about type systems, but it’s pretty clear he’s thought through his position and random folks on the internet screaming differently isn’t going to change it, it’ll just make his job more difficult. I can’t imagine ever wanting to do that to someone.
It’s been my experience that the folks who can provide helpful feedback about mistaken technical decisions rarely howl. They can usually speak pretty clearly about how decisions impact their work and are able to move on when it’s clear there’s a fundamental difference in goals.
According to https://www.mercurial-scm.org/wiki/UsingExtensions – there are at least 6 sub-repo extensions. And, yes, ActiveDirectory logins, other SSO variations and then on top of those multiple ACL layers.
As for MQ – absolutely you can avoid it with others tools that can produce the same sort of history… rebase, graft, strip, etc. The issue being if all the “how we work” docs are written in MQ style – it is a bit of mental gymnastics to convert over.