cel1ne

The way private visibility is handled is actually pretty useful for data-structures like Linked-Lists or trees where one creates more of itself and needs to adjust internal pointers without providing an external interface for anyone else to do so.

I agree. That’s why I pointed out that a necessary addition to get more productivity out of writing custom parsers is

a) easy usability in shellscripts B) easy tooling for unittests

I started writing shellscript in kotlin, so i get the unittests for free

Which IDE do you use?

Did you use IntelliJ IDEA for kotlin? If not you're missing a giant part of the experience and ease-of-use.

Kotlin can compile to Javascript too. Just saying.

It won‘t work. The mechanism that hides the timing information from untrusted code will itself leak timing information.

You just need to refine statistics. The underlying program can‘t be solved in a physical universe.

I'm flabbergasted about the carelessness of these companies.

The world basically figured out that everyone can have their own currency, so now every little company starts to print their own money?

Why are people buying monopoly/play-money for dollars? Because CPU-time was wasted to make it unforgeable?

What use does unforgeable money have, if it's not irreplaceable?

Why are buyers not concerned that their freshly purchased ToyCoins are rendered useless in the blink of an eye by the issuance of ToyCoin-2, perhaps by the same company?

Still, but in practise you can adapt in a mediocre way to new scaffolding by copying large parts. That way you introduce new bugs, which is part the problem we're talking about, but you kept it alive for another couple of years by relatively low effort.

Apart from the social issues there‘s a nice cognitive corrective described in „heretics guide to best practises“.

1. optionally divide your project in arbitrary smaller tasks

2. for each subtask pick a range (min and max estimate) so that you‘re sure the actual time lies in the range 90% of the time.

3. imagine the following decision: you can draw one out of 9 black and 1 red marble. If you pick the red you get 10.000$. That‘s a chance of 90%.

OR: you can choose your estimate and get 10.000$ if it‘s correct.

If you think about this decision and rather pick the marble-game, then your estimate is too narrow and most likely not correct.

If you pick your estimate over the marble game, it‘s too wide, because you‘re more than 90% sure about it.

Adjust your estimate until the decision doesn‘t matter anymore and both the game and your estimate seem like equal chances to you.

4. my own addendum for people who are afraid of asking too much: double the result to take the stress of yourself.

There‘s a single reason software doesn‘t work like that:

Bits don‘t fall apart.

If you can have a perfect copy of something you can easily keep it in existence forever.

If not, your artifact will sooner or later decay. It will only prevail through conscious action, being subject to incremental evolution of thought. Which copies are not.

The GDPR law in the EU allow us-companies to be fined: https://community.spiceworks.com/topic/2007530-how-the-eu-ca...

As far as I know they have to provide schematics and documentation about how and where they process data.

Yes or they could be fined 20 million dollars or 4% of their revenue: http://news.ycombinator.com/item?id=15769773

It was a joke on my part. There is a lot to do actually. Deal with climate change foremost.

And it does so quite efficiently.

Not an expert, but it seems that proof of stake is just obscured proof of work.

http://www.truthcoin.info/blog/pow-cheapest/

Date-handling should work in 100% of cases.

You can built syntactic sugar around js-joda too.

I develop Java/kotlin as well, so I'm used to the API. It feels verbose, but it makes a lot of sense. Date-handling is complex, a library shouldn't hide that.

Isn't there also the issue of fuel-reserves (uranium etc.) actually not lasting more than about 50-100 years?

PLEASE use joda-js on Javascript: https://js-joda.github.io/js-joda/

It's a port of the java8 date/time API, which is the most correct date-handling library there is.

EMail me for a promotional code.

Everytime I read a HN comment claiming a language to be „blazingly“ fast, i wish they posted a link to statistically sound benchmarks, including vm-warmup, GC collection times, etc.

Otherwise I just throw these adjectives away. I argue a new compiler/interpreter will always lose against the JVM, which has thousands of man hours of optimization built-in.

The JVM in turn will always lose against a clever memory-conscious lowlevel-implementation in Rust or C or assembler.

Please don‘t advertise speed without any studies or comparison to back up that claim.

There's a way around that: First time, you do it "like a sketch", no criticism allowed. Then you can work over it. Every creative work that ever got finished was made like that ;).

Better finish 80%, than miss 100%.

I'm reading Annotations on Java-Code and generating classes from them, so I need to parse Java first.

I wrote an annotation processor for [0].

If you use Kotlin instead of Java it's way better because no nullability-issues and it's super-useful standard-library.

And once you've figured out how to hook it into gradle, IDEA etc., which admittedly cost me an hour or so, you can reuse that knowledge for every annotation-processor to come.

I made it a habit to set myself a time-limit EVERY time I start touching the build-process. After the limit has passed it must be faster, more automated, or in any other way more useful, or I will revert the changes.

[0] https://medium.com/@spitzwegerich/generated-json-serialisati...

But how do you access the original AST in your python?

The main problem with JS being sluggish (in electron apps for example) is memory and especially the GC.

I can optimize CPU usage all I want, but only after I optimized for minimum allocations, the tiny, but noticeable lags now and then would disappear.

The average javascript-GC must be really simple/naive compared to seasoned workhorses like the JVM's various GCs.

There I can happily create millions of short-lived objects before getting problems in a single-user application.

I can remember playing it with my Voodoo card. T2 had Glide support and with that on, you could see much further than players with OpenGL cards.

More tips: * Never use object-relational mapping * Use postgreSQL instead of mySQL * (optionally) switch from PHP to python

A book recommendation: https://www.amazon.de/Heretics-Guide-Best-Practices-Organisa...

No, but I'll might write it up at some point.

So much to do, so little time ;)