If you think people are worried when stock prices are falling, imagine what happens when they all go to zero. That's what happens when you close the markets: stocks can't be sold and thus have an effective value of zero.
Much of the fall so far is bringing prices back to reasonable levels after a record-setting bull market. Not that that's especially fun news; between that and a genuine recession coming up, a lot of people will lose a lot of money. But it means that, as scary as this is, it may also be necessary, and even beneficial. (In the "long run", that is, and in the "big picture". Still sucks for a whooooole lot of people for a very long time.)
Think of it as putting someone in a medically induced coma. It's not really a terrible idea. Anyone working in finance could enjoy the downtime and use their time to help local city/hospital/neighbors etc. US bails out finance, finance in turn pitches in. Could be a nice win-win.
Well typical financial advice is to keep at least 3 months of expenses in a savings account or other very liquid account as an emergency fund. So plenty of people likely follow that advice.
The US govt just said that strict social distancing measures could last till August, plus there could be a recession coming. It's entirely possible that many people could be laid off and may run low on emergency funds if this goes on long enough. And many Americans could be facing huge medical bills to pay for treatment.
I'd say it's extremely likely that some unfortunate people are going to need to do hardship withdrawals from their 401ks to avoid eviction. Not everyone is in such a secure position that they could be cut off from their assets all in the name of calming the financial news.
There are many institutional investors such as pension funds and insurance companies (whatever they call their holdings) that rely on returns from things like stocks.
Since they wouldn't be able to sell stocks, they would start selling everything else they've invested in.
Same would go for anyone else requiring cash.
Then everyone holding the other stuff that is liquid, will sell it because why hold onto a plummeting asset when the only reason to own it is the value?
The same reason why not testing for the virus doesn't stop its spread. Markets can spread psychological panic very quickly, but a lot of the short term behavior here is based on very short term bets about what other people are going to do on average. Give the market a month to integrate some information that is relevant over slightly longer timescales and we'll see where it thinks we are.
It will just make things much worse. Without a liquid market for stocks, no matter how bad the whole economy would grind to a halt at some point. Though we're a long time away from the next IPO (by my guess) as long as there are buyers the market should stay open because that will allow a lot of entities to fulfill their obligations. If you close that avenue off there will be a severe knock-on effect from institutional investors that suddenly find themselves without liquidity. That's a scenario that I'd rather not contemplate.
The 'no buyers' scenario in fact did play out two weeks ago, there were 1.8 million shares of Shell for sale on the Amsterdam exchange without buyers. Shares to be sold without reserve, and yet, no buyers. It took a long time to fill those orders and that's why Shell did not have a price on the board during that time. Never, ever, happened before.
He also used a compiler, but real programmers never do that. Maybe he used an IDE like Visual Studio that does a lot of real-time checking to make sure the code is correct before the compiler runs. Don't even get me start on the fact that he used off an off-the-shelf von neumann machine. Basically, the ghost of Von Neumann did allllllllllll the actual work and this guy is taking all the credit.
If you aren't writing your own Turing machine code in a language you developed, proved that language is Turing complete on the system you built, by hand(no help needed right?), that simulates the Turing structure on a state machine, you are not a programmer. Then, of course, wrote the OS(what's the name of your OS? I trying to become a real programmer and needs some pointers on scheduling). Don't forget to come up with your own machine learning model that doesn't use any of Shannon's llllllllame theories, doesn't rely on SVMs, neutral networks, or those weird upside trees(yuck) that those total losers with no programming skill what-so-ever, use.
Oh wait, you're still not a real programmer then; I almost forgot that the CT thesis is TOTAL unproven BS. No real programmer would stand for that. They are so logical and perfect in their understanding. So, if you can spare a minute from all the real programming you are doing, you should probably come up with your own model of computation, just so no one calls you out for not being a real programmer. Which, of course, you are. Wolfram did it and _everybody_ loved his "original" work. Of course, you'll then prove that this model can solve the halting problem in O(1). Wait, wait, wait, while you are at that, the PH hierarchy is also total unproven BS(look at me being so forgetful, I'm just not a real programmer, yet). Can you even believe that all those idiot nonprogrammers ever proved was P < EXPTIME, duuuuuuuuuuuh. You'll need to come up with your own classification system that isn't so broken. You don't even need to do much(what is NP even? And who decide to call it Merlin-Arthur? Is that a joke? Real programmer never joke about code.) because all your real code will run in polynomial time and always be deterministic...
What a Charlatan, amirite?
Programmers/Data Scientists stand on the shoulders of giants so large it is a serious undertaking to fully realize just how high up one truly is.
The Peano axioms don't do very much, they just help model the natural numbers. You still need something to model the logic and provide foundations more complex subjects like analysis.
> sys_overlay, a special way for games to load external code. While it is very much a work in progress, it shows real promise because Metal Gear Solid 4 needs it to run
I think woo usually involves claims about how some pseudoscience nonsense can impact an average person's life. The multiverse isn't used in this way, from what I've seen.
Oh yeah, there is tons of various "quantum" woo. Deepak Chopra comes to mind as one of the well-known worst offenders. But I think that is separate from the OP, which seemed to mostly be about the multiverse (and actual physicists).
There's has been a mini resurgence in C from (normally high level language) programmers who are getting sick of web development and are interested in data oriented design.
Conference benefits could be:
Pushing the C standard. C11 is barely supported.
Discussing new standards in a forum other than mailing lists. Did you guys know there is already a C17 standard?
Letting old C devs pass on their wisdom to new C devs. C has a lot of pitfalls but also has a lot of neat tricks.
The problem is that nobody new to the scene wants to write C anymore. It's not a secure language, it has no convention and is full of hacks. On top of that it has undefined behaviors and is supported differently by different systems.
Nowadays people want to write in Go, Rust, Swift, etc.
Of course, for now. But I still disagree that it is as easy (or hard) to write C without bugs as in any other languages. Most people should not write C.
In the same vein - if you happen to be stuck in a problem domain where counting/avoiding allocations is important the other languages I listed above (even C++ really) make things very hard. Rust has a decent take on building a safer c++ (with what appears to be C++ levels of complexity). Would like something similar to emerge for C.
C is so much fun though. Having so much direct control over everything, no layers of abstraction clouding your view, is incredibly enjoyable in the right context.
And you'll struggle upstream if you go that route. Pretty much all vendors for embedded platforms only provide C libraries/drivers/examples/subsystems/documentation.
The compiler vendors I listed are vendors for embedded platforms, they also sell boards.
The problem, as expressed multiple times on C++ conferences, is the devs that are religiously against anything that isn't C89 + language extensions + Assembly.
Surely I know that, but there is this image being sold that C is the only option, when those companies that I have listed are in business for at least 20 years now.
I also know there are a large amount of people in the trade that have zero regard for writing secure C code, despite the availability of tooling to help in such regard.
Which is getting worse now that those systems are being plugged into the Internet.
Sure, I've seen embedded work done with anything from assembly to Lisp. But it's all marginal, trying to get into embedded development without learning C would be very career limiting. For example, not sure how many new projects are started in 2018 with Pascal on PIC but suspect not a lot.
Perhaps the most popular non-C development platform these days is Arduino on Atmel 8 bit chips, but it is still really a dumbed down version of C(++).
> Letting old C devs pass on their wisdom to new C devs. C has a lot of pitfalls but also has a lot of neat tricks.
On this topic, does anyone know any good blogs along these lines? I'd love to read some practical day to day stuff from people that have been working in C for decades, usually all I see from places like HN are weird compiler incompatibilities and rare exceptions that I never have to deal with.
Most of my experience comes from toy projects and horrible decades old code I deal with at work. The former is great for trying out ideas but I don't learn how they scale (human wise) on larger longer projects and the later is more a lesson in what not to do.
if you are willing to pay for private email, why not any of the dozens of existing ones? e.g. protonmail or fast mail? there is little differentiation available for them here.
I honestly think Zig has the potential to be the C/C++ replacement. I haven’t checked out Jai yet but will now that you mention, thanks!
This is somewhat subjective of course, but from what I’ve seen, Zig has just the right set of features to modernize systems programming, without making the language too complex or difficult to write (which arguably Rust’s “borrow checker” system does), and (like Rust) gets rid of some huge legacy language design mistakes most people agree on today (e.g. nullable-by-default pointer types, or no way to know at compile time or at a glance what range of exceptions a function may throw).
And of course, the “automatic” interoperability with C is an essential part of any C/C++ replacement contender.
There are a lot of contenders. My own unsorted list is Nim, Rust, C++20xx, D, Objective C, Pony, Zig, Crystal, Red, and maybe a form of Lisp (why not Common Lisp). Even more unlikely a maybe and only for the C/C++ trenches of embedded systems, some form of Forth. If Jai ever ships I might consider adding it (at least as a contender to the C/C++ trenches of games and game engines), but it's absurd to think it will have any impact when it can't even be used by anyone other than jblow yet. Even if it ships, I would bet its highest anywhere-realistic impact (which is still damn high) would be to become the PHP of game programming. The mythical C/C++ replacement that everyone will choose when they previously would have chosen C or C++, causing C/C++ to die like COBOL? Much less likely.
Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references.
Rust, Zig, Kotlin, Swift, and many other modern languages can express the same concept of a null reference, but in a fundamentally superior way. In modern languages like these, the compiler will statically guarantee the impossibility of null dereference exceptions, without negatively impacting performance or code style!
But it goes beyond just static checking. It makes coding easier, too: You will never have to wonder whether a function returning a reference might return null on a common failure, vs throw an exception. You’ll never have to wonder if an object reference parameter is optional or not, because this will be explicit in the data type accepter/returned. You’ll never have to wonder if this variable of type T in fact contains a valid T value, or actually is just “null”, because the possible range of values will be encoded in the type system: If it could be null, you’ll know it and so will the compiler. Not only is this better for safety (the compiler won’t let you do the wrong thing), it’s self-documenting.
It blows my mind that any modern language design would willingly think nullable object references is still a good idea (or perhaps its out of ignorance), when there are truly zero-cost solutions to this — in both runtime performance and ease of writing code, as you can see for example from Zig or Kotlin.
Null isn't that bad -- or rather, the concept of a missing value. Certain languages handle null better than others, but even then, it seems like the more costly mistake has been the accumulation of made-up data to satisfy non-null requirements.[0] More costly for non-programmers who have to deal with the programmers' lazy insistence that not knowing a value for some data in their system is forbidden, anyway.
In any case I think the modern fashion of trying to eliminate null from PLs won't matter much in the effort to replace C, whereas something like a mandatory GC is an instant no-go (though Java at least was very successful at sparing the world a lot of C++). OTOH a language that makes more kinds of formal verification possible (beyond just type theory proofs) might one day replace C and have null-analysis as a subfeature too.
I think the author of that blog post fundamentally misunderstands the point: The damage of nullable pointers is not that they are nullable, but that compilers allow you to write code everywhere that assumes they’re not null (in fact, this is the only possible way to code, when the language cannot express the notion of a non-nullable reference!)
For example, most older languages with “the billion dollar mistake” have no complaint whatsoever when your write “object.method();” where it’s unknown at this scope whether “object” is null or not.
The fact that such code compiles is the billion dollar mistake; not the fact that the pointer is nullable.
I don’t care if you want to write nullable references everywhere, or whatever else you prefer or your application demands. That’s fine, so long as:
1. Non-nullable reference types must exist.
2. Nullable references types must exist as statically distinct from #1.
3. The compiler must not let you write code that assumes a nullable reference is not null, unless you check via a control flow statement first.
Now to take a step back, the principle behind this certainly applies beyond just nullability (if that was the point you were trying to make): Generally, dynamic, untyped invalidation states are dangerous/bad, while statically typed invalidation states are ideal. And yes, this does include bad states internal to a non-null reference, just as much as to a null reference.
Sum types are the key to being able to statically declare what range of values a function may return (or accept), and ensure at compile time that these different cases are all accounted for. If you aren’t aware of how elegantly sum types solve this, you should look into it — and I suspect it will be quickly clear why nullable references are useless, outdated, and harmful.
But at the very least, we’ve solved the pain of null dereference — and virtually without compromise. So, it’s irresponsible or ignorant IMO to create a new language that doesn’t include this solution in its core.
It doesn't seem like you are familiar with how option types get rid of null. You don't have to make up data to satisfy things not being null. You set them none, and the language either forces, or encourages usually, you to always check if the option is none or some.
I use Option in Java quite a bit because I'm real sick of NPEs and cascading null checks in all-or-nothing flows. I would have preferred Java starting with something like Kotlin's approach where T is T not T|nil. You and the sibling might be missing the point of the post I linked, I think. It can be convenient to have formal assistance via e.g. the type checker that a function taking a non-null String returns a non-null Person with a non-null FirstName and LastName. But in the zeal to be rid of null to make programmers' lives a bit easier, when faced with a name that doesn't compose into 2 parts, someone has to decide what to do about that and who needs to care down the line. You can make up data ("FNU" as in the blog), set a convention (empty string), throw an exception, or declare either the whole Person structure Optional or at least certain fields. If you use a dynamic late-binding language you may have other options. Whatever you do, it ought to be consistent or robustly handled where the references interact with your DB, your processing programs, and your data displays. Finally when these references escape your system, as lots of real world data does, they necessarily escape any static criteria you once had on them, thus it's important to consider those third party systems have to live with your choice. Null is a convenient choice, not something to be villified so casually.
> the compiler will statically guarantee the impossibility of null dereference exceptions,
almost every language that gets rid of nulls with something like the Option type will let you still bypass it and get a null reference exception. Rust lets you unwrap, F# lets you bypass it. You could at least enforce a lint that doesn't allow the bypasses in projects where that is desired though.
Yes, but there’s a big difference between the default member access operator crashing conditionally based on null-ness — vs — the same operator guaranteeing deterministic success (thanks to static type checks), with the option to circumvent those safe defaults if the programmer really wants to (in which case they usually must be very explicit about using this discouraged, unsafe behavior).
It may seem to be just semantics, but it’s really quite important that the default (and most concise) way in these languages to read optional values is to check if they’re null/None first in an if statement, after which you can call “object.method()” all you like. It’s important that you can’t just forget this check; it’s essential to using the content of the optional, unless you explicitly type something like “.unwrap()” — in which case there’s almost no chance the programmer won’t know and think about the possibility a crash. Take this in contrast to the chance of crash literally every time you type “->” or “.” in C++, for example.
Perfect is the enemy of good. By reducing the possibility of null dereference exceptions from 100% to 10% you have reduced the cognitive burden by 90%. Removing the bypass would result in a 100% reduction in cognitive burden, only 10% more than the second best solution. However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those 10% fall under. In those cases handling the error "correctly" is actually an additional cognitive burden that can ruin the meager 10% gain you have obtained by choosing the perfect solution.
> However handling null cases correctly isn't free either. Especially when you know that a value cannot be "null" under certain conditions which those 10% fall under.
While I agree there are rare cases where .unwrap() is the right thing to do, I actually disagree here that it’s anywhere close to 10%: If you want to write a function that accepts only non-null values in Rust, you simply write it as such! In fact, this is the default, and no cognitive burden is necessary: non-nullable T is written simply as “T”. If you have an Option<T> and want to convert it into a T in Rust, you simply use “if let” or “match” control flow statements.
I actually think using .unwrap() in Rust anywhere but in test code or top-level error handling is almost always a mistake, with perhaps 0.001% of exceptions to this rule. I write code that never uses it, except those cases mentioned; while I’ve run into situations where I felt at first .unwrap() was appropriate, I took a step back to think of the bigger picture and so far always find safer solutions to yield a better overall design.
The cognitive burden from Rust comes not from this, but almost entirely from the borrow checker (a completely different toptic), and in some cases, arguably inferior “ergonomics” vs how Zig or Kotlin handle optionals.
For example, in some null-safe languages, you can write:
if (myObject) { myObject.mehod(); }
And the compiler will understand this is safe. Whereas, in Rust, you must write:
if let Some(x) = myObject { x.method(); }
This is not even to mention that Rust has no built-in shorthand for Option<T> (some languages write “T?” for example), but I understand why they chose not to build this into the language; rather, Option<T> in Rust is actually a component of the stranded library! In a way, that’s actually quite cool and certainly is by-design; however, it doesn’t change the fact that it’s slightly more verbose.
IMO it’s not a huge deal, but certainly Rust could benefit from some syntax sugar here at least. Either way, both examples here are safe and statically checked by the compiler.
Yeah I think unwrap is best used when experimenting/prototyping, but it can be very very useful there. Imagine trying to get started using Vulkan or Opengl without it. Big mess. But in production code you might want to lint it as a strong warning or error.
> Many of those are ruled out as modern successors (in my mind, at least), when they continue to make “the billion dollar mistake” (to use its inventor’s own words[1]) of null references.
Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.
> Well, you're in luck then! You don't even need a 'modern' successor, C++ (even the ancient versions) disallow null references.
That's useful, until you realise that all its smart pointers are semantically nullable (they can all be empty with the same result as a null raw pointer) and then nothing's actually fixed.
What you mean is that C++ doesn't have a way to (easily) let you check whether a given reference is null or not. int* a = NULL; int& b = *a; compiles and runs just fine.
No the gp is correct, references in c++ can't be null. Your code invoked undefined behavior before you did anything with a reference, namely *a which is a null pointer dereference.
Which is a textbook example of the null reference problem.
Edit: There may be some terminological confusion here: when programming language folks talk about "references", they include in that definition what C/C++ call "pointers". See for example the Wikipedia article, which gives as the C++ example not C++ references, but C++ pointers.
The "null problem" is that a static language does a run-time check instead of a compile-time check. By the time the undefined behavior is invoked, compilation ended.
I was looking for a way to do metaprogramming, verified programming, LISP-like programming, and low-level programming. Past few years of searching led me to a lot of verification stuff obviously, PreScheme for low-level Lisp, ZL for Scheme/C, and Red/System for a REBOL-like answer. I was eyeballing Nim, too, since the masses usually hate LISP's syntax. Then, I thought a front-end that let one go with various syntax's, esp inspired by famous languages, with the same underlying semantics or just easy integration.
On a practical note, I noticed that strong integration with the dominant language with little to no performance hit is extremely important. Clojure building on Java in enterprise space is an example. It reuses it's ecosystem. For system space, I started recommending using C's data types and calling conventions where possible in new language so calling it would cost nothing. Then, maybe an option to extract to C for its compilers. So, whatever above languages are created need to integrate with C really well.
I hadn't heard of Jai yet, but wow! That's a lot of hype (and even tool support) for something that doesn't work yet.
At first glance, Zig vs Jai reminds me a lot of the Linux vs GNU Hurd thing (or a lot of other "worse is better" examples). A couple of geniuses locking themselves up telling the world "Just wait! It'll be awesome!" seldomly produces something that lasts.
Yeah I guess. The only charitable thing I can think to say is that maybe they've tried all the others and found them lacking somehow (what language is perfect, after all?) and so they put their hopes to the one as yet untested.
It could, theoretically, be perfect. Since it's all theoretical at this point I mean.
