If the reason understandability is important is that it means you get fewer defects etc, then really it isn't that it's important, it's that defects etc are important. This article is completely confusing means vs ends.
Surprisingly, yes, there's really not a lot of McDonald's or other chain fast food restaurants downtown. You can try exploring in Google maps to get a feel for it (consider eg the area around Mercer and Dexter Ave). You can get to one, but it may be a half hour detour on foot. What is closer will be awkward as they describe.
Thanks for that. I have to agree to being surprised. I've just looked on maps from my last Sydney office, for some comparison: There's a McDonalds at 377 George St and at 600 George St, both about a four minute walk. There's a third inside the Westfield which would have its own bathrooms. KFC is three minutes away with bathrooms.
The Marble Bar is a 3m walk, Century Bar is 5m, Ryan's Bar is 9m, Burrow Bar is 5m, and Papa Gede's is 3m. All of this excludes the mass of pubs and clubs that shutdown due to lockout. I definitely feel out of place with what you've shown me!
The snark and meanness in this HN thread is totally uncalled for and why people don't publish code. I can't believe this thread is on the front page together with https://news.ycombinator.com/item?id=23157783 . Go read that, especially the ending comments on open source.
> I made this thing that I thought was cool and I gave it away, and what I got back were occasionally friendly people who nicely requested things from me, but more often angry users who demanded things of me, and rarely anyone saying thanks.
The issue here is the link; it doesn't do a great job of explaining _why_ Bosque is breakthrough. A bold claim like that needs evidence.
What's special here? From glancing at the code snippets--which is really all we have in the way of evidence on that page--I see an interesting language concept, but it's not entirely here how that relates to the initial claim.
There are definitely some interesting elements, though. It looks like it borrows a lot from TypeScript and C#, then attempts to make the resulting syntax a bit stricter with various forms of contracts. I think the goal is to make stronger guarantees at compile-time and promote better design practices. That, in turn, can result in faster applications because the compiler can make more assumptions.
If that is the goal, it needs to be explained more clearly in the readme before receiving widespread publicity, and there needs to be text explaining how each feature achieves that goal. A big part of developing a new programming languages is selling it: you have to convince a lot of opinionated people that it's worth their time and energy to invest in learning your technology.
Ideally, these arguments would be written during the design process before implementation even begins, so I don't think it's unreasonable to expect that they be available in the readme.
This is a much better link. Bold vague buzzwords on the GitHub page ("a breakthrough research project", "a high productivity development experience", "an unprecedented tooling ecosystem") inflict antagonistic mood towards the whole project.
Gets me pretty excited though. MS has a track record of productive dev experience and great tooling ecosystems. I’m actually looking forward playing with this!
> see an interesting language concept, but it's not entirely here how that relates to the initial claim.
I didn't see any concept which wouldn't be practiced in PL design for decades. Yeah, they may not be widely known, but suggesting that "structural, nominal, and union" types are anywhere near any kind of "breakthrough" is just too much. If anything, the language seems conservative in its design rather than novel.
Right, I don't see the justification for "breakthrough" on that particular page. It's interesting in that it's attempting to bring more performance to the JS world using old tricks, but from that page alone, I wouldn't call it breakthrough. I'd need to see more concrete justification for that term. It's possible that the compiler itself is truly groundbreaking, but that isn't really addressed in the readme.
I actually went through the language doc, which describes the language in more detail (there are still some WIPs and TODOs). I was able to name at least one language which would be considered "prior art" for every one of the features detailed there. A good deal of languages also come close to supporting all of them in one package, and languages that offer most of the features are a dime a dozen.
There are a few mentions here and there which do look interesting, but whatever the "breakthrough" turns out to be - and maybe there really is one - it won't be in programming language design for sure.
This can almost be said for many languages, even the popular ones like Rust which didn’t event most of the things it does.
Who cares? It’s all about how they put it all together. Plus some of the IR stuff is interesting.
Basque strikes me as a better attempt at a new Typescript than Reason. I really like that they are adding things like check, assert, validate into the language itself. I mean it just looks far better than TS in every way, especially once it starts to optimize all the language information it has. And it’s totally fine it’s not new. What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.
I’m curious the interop story. Performance stats. DX. Look at TS vs Flow. I tried both numerous times and it was just so obvious TS was leagues ahead - far easier to set up, work with existing code, nicer errors (early on), and they just relentlessly improved it while Flow was crickets.
I don’t care so much about it being a breakthrough (though I can see how it’s basically as big a breakthrough as Rust, if it’s done right), but that it becomes viable. Sure, Reason or any of the other hundred I’ve seen come and go over the last few years would be cool too, but for whatever reason they aren’t “catching” fully. Reasons interop is finicky, the language is very verbose, and it’s just been way too quiet (where are the big releases?), but they got most of the rest right. This seems to get as much if not more right, so we’ll see if MS pushes it like they do TS, I hope so!
> I really like that they are adding things like check, assert, validate into the language itself.
I'm not sure. Contracts are supported in some other languages as a library feature; recent examples I encountered were Elixir, Scala, Clojure, and Haxe; there's also, of course, Racket, but there it's hard to say where the library ends, and language begins... Eiffel, Cobra, Pyret have contracts as a language feature - it may be easier to support it that way instead of first making the language expressive enough and then writing that library.
> What matters more is that it puts them all together in the right way, moves at a good pace, gains traction.
No, out of these only the last one matters: there is no "good" pace (you're either moving too fast or too slow), and there is no "right" way to design a language. The only thing that matters for a language is to gain traction - otherwise, it dies - and that seems to be almost entirely unrelated to the technical features of the language. Luck (e.g., C, Python, PHP) and money (e.g., Java, C#, Go) seem to play a much greater role in making a language successful, along with vendor lock-in (e.g., Objective C, Java, C#).
The lag between an innovative feature conception and its implementation (in the mainstream language(s)) seems to be 10-20 years on average, but it can sometimes take 50+ years while a feature is repeatedly discovered and forgotten in 10-20 years cycle. For example, there are optional static type systems (for otherwise dynamic languages) in languages from the '80s (ie. Common Lisp) and '90s (ie. Dylan), and the more formal gradual typing is IIRC from 2001 (by J. Siek). TypeScript, Flow, Python's mypy, and similar solutions are a mainstream-ish emanation of these ideas - it them took some 15 years to materialize and a few more to appear on the "working programmer" radar. This is a very common pattern: basically, if you want to know how programming will look like in a decade, you can simply look at the experimental features and ideas from 10+ years ago.
Thanks for the link, it is interesting. I’ve wished for the "Typed Strings" feature in C# a number of times, including today, so I hope it will be ported there one day.
>Stronger assumptions at compile time allows for higher quality code
this depends very heavily on your definition of higher quality code. I really hate this new trend in language discussions of declaring subjective benefits to be objective.
Stronger compile-time assumptions, by definition, reduce the scope of runtime dynamism, which, for many people is an important feature of say dynamic languages.
Stronger assumptions at compile time are part of a trend of attempting to verify programs formally ahead of time, which is not the only way to produce robust software, but seems to be increasingly treated as such.
What can you do with runtime dynamism that I can’t do with a language using a strong type system with dependant types? You need to know _something_ about the dynamic data else you can’t do anything with it and that starts to suggest there’s a structure you can declare, right?
And what methods do you think are as capable as formal verification? What I mean by that includes formal specification, property based testing, theorem provers etc.
Edit: This reads argumentative but that’s not what I wanted, I’m genuinely interested.
That's a bit vague; do you mean MIT-licence-then-patent-troll, or MIT-licence-then-charge-for-security-updates, or MIT-licence-then-lots-of-'optional'-extras, or ...?
std::move should extend the lifetime of a temporary like static_cast does. (Or else not accept temporaries). Otherwise, no new features necessary. But that one bites sometimes.
SEC yield already includes expenses, so it's just 2.99%. (The actual dividend yield is 3.08%. I don't know where the other .06% comes from, but IANAA).
That's an entirely separate issue, and one to be filed under "problems we'd love to have to deal with". Fairly sure it's lower on the priority list than "heat death of the universe", which we'd also need to deal with.
The original sense is "No parking on sundays" proves that parking is allowed on other days.
The colloquial sense is that if something is a surprising, it shows that its opposite was a useful rule of thumb, or at least one you'd established in your head. (E.g. if you are surprised by a dog that doesn't bark, this surprise is meaningful and says something about what you think about dogs and barking.)
If palantir is shocking as a SV company, this says something interesting about what you think about SV companies.
