Recent submissions

Comment · 5 years ago
Comment · 5 years ago
When your system is replacing some existing system, which could well be just paper-based, it is very useful to study it carefully. It will give you a good idea about the data and its internal relations. If you want to show something to a customer, you can also simple mock-ups like static HTML pages.

Only after you have a decent understanding of the system you should start building it. There will be many new requests, but most will just be concerned with the UI. If you have the right data model and architecture, those will not be very difficult to solve.

Comment · 5 years ago
With an AOT compiler a lot of work is done at compile time, but with JIT it is done at runtime, which makes these programs slower to start. But for programs that do run for a longer time, like servers or IDE's the performance is quite decent. But Java is a memory safe language which means that it has to do a lot of checks that unsafe languages do not have to do, which means that it will always be slower that unsafe languages. In some cases the JIT can eliminate those safety checks, but that is not always possible.

Java always had (and still has) an AOT that compiled to byte code. Adding JIT was a major improvement.

Comment · 5 years ago
We certainly do deserve better, and the author made some good suggestions.

Unfortunately, building a new database is a huge project and there appears to be no party currently willing to sponsor it.

Comment · 5 years ago
> An example here is how, sure, in theory, JITs can outpace AOT compilation because they have all the information the AOT compiler has plus runtime insights. But the ability to truly do that always seems to be a decade of compiler development away, with many giving up on the idea entirely.

JIT has been used very successfully for a couple of languages, e.g. Java. But adding it requires a lot of effort. The same thing is unfortunately true for new query languages, building a new database is really expensive, this is probably the main reason that there have been no serious alternatives to SQL.

Comment · 5 years ago
My country, the Netherlands, has been struggling with water for its entire existence. A large part of it is below sea level.

In most parts we have two different drainage systems, one for rain water and one for sewage. All sewage is processed in treatment plants before it is released into open water. We don't use open water directly as drinking water. Either we use ground water or use river water that has been infiltrated into our dunes.

There are probably some things that the US could learn from this, but it will probably come with a very high cost.

Comment · 5 years ago
One of the big problems with "modern development projects" is that they start coding from day 1. The first step in any good project should be to learn as much as possible about the requirements before making serious decision about its architecture. Designing a model of the data (even if it is only a very rough one) is usually very helpful in the first phase of a project.

It is still true that mistakes that are made during early phases of the project are much harder to fix than recent mistakes.

Comment · 5 years ago
A better idea would be to choose a random submission from a larger number of submissions. This would prevent most attacks. Any duplicate submissions should be flagged and there should be a penalty for users that submit them.
Comment · 5 years ago
When there is good public transportation the need for cars will decrease. Also when buildings increase in density, public transportation will become more profitable.

South Korea is a fine example where this worked. The cities are very compact but have excellent public transport. It will be difficult to achieve something similar in the US.

Comment · 5 years ago

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton