That's incredibly concise. I see you're perturbing vx and vy randomly and updating location accordingly on every frame. Is the perturbation also per-frame or is that block of code just executed once? Is randomf a floating-point number between 0 and 1?
Your point of view is very clear: it's not a feature you're interested in. But it doesn't mean that it's not a good feature for the person who has opened the issue.
Instead of convincing them that it's a bad feature or talking about why it's uninteresting to you, just point them to a CONTRIBUTING.md and stop engaging with them after that. If they're actually serious about the feature, they can implement it in their own fork (which then you can request as a PR if you want it in your repo).
You're right! Even I tried to post it. This is what I observed:
1. After posting, I'm redirect to https://news.ycombinator.com/newest where the link works
2. I click to open the discussion, now on this page link no longer works
3. Going back to /newest, the link no longer works!
1. Would it be correct to describe memoized DOM approach as combination of direct manipulation (like hand-written jquery, or what svelte compiles to) + a mechanism to avoid invoking selectors by caching references to DOM elements? Or is there more to it?
2. It'd be a good experiment to separate out the memoized DOM implementation from imba codebase in a way it can be used by different frameworks, just as virtual DOM libraries got popular after react. If someone were to attempt this, where would you recommend that they start with the imba codebase?
I've always viewed Julia as a language for scientific computing professionals [1].
The article pronounces Julia's death only based on popularity relative to other languages. Yet, it's not clear what the author is comparing it to.
The comparisons I see are MATLAB and FORTRAN, to which Julia seems to stand third in TIOBE Index [2] that the author is using. The author doesn't seem to focus on this.
The author mentions
> Julia’s target user is harder to define. I have struggled with this while writing Learn Julia.
I wonder if it may not be the case that the author has developed his own notion of what Julia ought to be. And I'll agree that Julia may have failed his grand vision to displace large parts of Python, but I do not think that that vision is based in reality. Python users that want to use frameworks written in other, faster languages (like C++) will forever continue to use Python and enjoy the vast libraries that it offers which aren't centred around scientific computing.
[1]: There seems to be a list on https://juliacomputing.com/. Arguably their needs might be very different than the author's. But I can't say because the article's arguments are not based on technical shortcomings.
[2]: In the TIOBE Index (as a proxy for popularity) MATLAB gets 1.04%, Fortran 0.83%, and Julia 0.41% (GNU's Octave, the main FOSS Matlab competitor, is nowhere to be seen). I do not know what these percentages mean though https://www.tiobe.com/tiobe-index/
It's important to note the methodology employed in the original paper used "did not have meaningful structure or variable names" [1]. If the code's like that, then yes it's less like reading a language and more like cryptic puzzles.
But limitedness of the methodology means the conclusion can't apply to software development at large, something that the title misleads us about.
But what do you think one gains by serving json instead of serving valid html like a body with just `<data src="actual.json"></data>`?
If you can retain full functionality (and hack on your ideas) AND be standards compliant (to make sure someone who decides to start offering a new web browser doesn't have to worry about 10% of websites serving this instead of valid HTML), then you should do that.
> there's open source alternatives to Play Services that Google neither litigates against nor seems to actively fight against
AFAIK these are reverse-engineered. Do you sincerely believe that developers' time is best spent reverse engineering and maintaining play services alts to undo a blockade that Google put in, just to be able to get full freedom over their android derivative? Wouldn't it be better spent in playing with cool new tech (as Google engineers seem to be doing)?
AOSP is an open source project, which is impractical for any business to run because of apps' reliance on proprietary google play services.
Chromium is an open source project, but proprietary chrome has the largest browser market share and they like to abuse their position to not play well with standards bodies.
Google can develop Fuchsia. It'll even be cool piece of tech, but I do not for a second believe that contributing to the project would benefit anyone but Google.
I smell this too. Sent them a mail 5 days ago inquiring about the claimed FSO advancea, packet loss metrics and company financials and they haven't responded.
Worse, the amount is just shy of typical angel investment but with their offering you'll likely have less rights than an investor does.
This is comical. It patents the entire system from HTML forms to get the input to prepare the SQL query, to server sending data as formatted HTML back to client.
This has been the bread and butter of PHP for two decades. I'm glad no one tried to enforce this to take away like 99% of the internet.