Only complaint is no TS support. Writing these kinds of libraries ones-self is a great way to learn about promises, async/await and the performance cost of iterables.
I was just trying to make a third party module out of npm, not making another dependency management. btw It'd be good to add the dedupe feature. appreciate for the feedback !
About a year ago I was on a big vagrant craze. We develop applications in JS and our primary deployment platform was Linux. We were hoping that if we developed in a linux environment, it would work better and it seemed like a pretty good idea. After a lot of usage, its slowness and quirks/bugs made it a bigger pain to use.
At least for our usage, it was pretty simple to switch our JS dev environment to support Windows (the primary development platform of our developers) without much hassle.
For now, If I need a VM, I'll stick to virtual box and maintain a persistent development environment, rather than something configurable and replicatable.
In the future I'd love to see someone take something like Docker and turn it into a development environment platform.
When I first started to use Vagrant I had slowness issues as well. However, through a bit of digging around I figured out that by mounting the shared folder through NFS and to create a swap file, pretty much all slowness issues disappeared.
It generally works, but debugging between components in different containers can be a real pain. For languages that don't support remote debugging in some sense you can be SOL (though that is perhaps true in vagrantland too)
Agreed. Although other comments claim that their dynamically typed languages have this same property, inherently in dynamic languages the auto complete will fail out unless you effective write code as if you were using static types.
These graphs really mean nothing. There is no data behind them. I might as well make a graph that conveys a non-descript correlation between how much an article bashes static typing & assertion and how high it is on HN.
They're just sketches. That's part of the point, and the article says that directly. The point isn't the exact shape or slope of the curves, but just their asymptotic behavior and the relationship of "correct features/day" to the other two. I.e. As long as the two curves have that general shape, then the "sweet spot" exists somewhere between 0-100%, the exact location of which depends on language, developer experience, and business priorities. The exact numbers are irrelevant to the article's point.
More realistically, it's an educated guess based off the author's personal experience as well as their understanding of the experiences of other developers operating under different constraints.
The author makes it clear that the analysis is not perfectly rigorous. There is a very wide landscape between perfectly rigorous and completely useless.
Do you think the article fails to hint at any of the fundamental dynamics of how type systems affect software development? How so?
I'm not who you're replying to, but for me the charts didn't make sense either.
For one example, I don't think it's a given that the green line (velocity vs % type-checked) should have a negative slope. Maybe in some cases, for some projects or some people, but certainly not universally. At least part of it would have been positive on almost all projects that I've worked on, and I'm not doing rocket science.
Then, the combined chart just looks at the amount of bug-free output, completely ignoring the amount of bug-ridden output. That latter part doesn't just get discarded, it needs fixing, and bugs that were only discovered in production are expensive to discover, debug and fix.
This is in addition to pretty much every other top level comment in this thread, a lot of which bring up important points that are unaccounted for even conceptually in the charts.
Quote -- "The answer of course is simple (and I'm sure many of you have already typed it up in an angry response). The curves I drew above are completely made up."
Think again--since when do graphs depict only cold, dry data? Graphs have always been useful for depicting relationships--real or proposed. Line graphs in particular are often found depicting proposed relationships rather than real data (though often inferred from data,) since for all cases where the real data is discrete, this would result in a scatter plot rather than a line.
You beat me to the same comment. It's pseudoscience. I guess they're measuring the anxiety at HN that people's sunk-costs in stringly-typed runtimes won't keep guarenteeing obscene salaries.
I've seen many articles lately about using Make for NodeJS, Go, and other modern languages. I really do not understand it. Lots of these languages (Go and NodeJS) were designed to be cross-platform or at least easily compiled on different OS's.
Why use a platform specific tool and restrict yourself to Linux? I'd prefer people find a similar tool that is designed to work on any platform.
The “restrict yourself to Linux” bit seems very odd to me: make is one of the most portable build tools in existence. Even 20 years ago it was common to have makefiles which worked on a dozen Unix variants (not just *BSD & Linux), Windows, OS/2, VMS, BeOS, etc. and it’s gotten easier over time rather than harder.
Were you perhaps referring to platform-specific tools called by a Makefile?
Huh? I use make all the time on Windows. You don't even need Cygwin, MSYS, or Windows Subsystem for Linux. There are make binaries that work well, for example:
That doesn't really matter, make is just a tool for your development environment, your code will be able to run on multiple architectures (which is what matters).
It works on OS X too. Linux plus OS X accounts for a lot of developers, though Windows probably still has the majority (but Windows is getting a Linux subsystem too!)
GitKraken is the best GitUI I've ever used. I highly recommend it. I use it for personal projects and at work. Professional License is really reasonable.
As much as i would like to agree with you, it should be a simple problem and there should be many comparable alternatives available, i can't because frankly all of the free clients in the wild suck in one way or another. I've been looking for years but everything i tried either looks like a cheap hack made with TkInter or lack one or two vital features. One might have a good branch viewer but lacks interactive staging, another client the opposite, etc.
I haven't tried gitkraken though, maybe it sucks equally much, my point is that there is an open market spot for good git GUI.
Been working more with Arduinos and lower level stuff to offset the high level work I do during normal work hours.