HN user

hasenj

4,763 karma
Posts32
Comments1,810
View on HN
terralang.org 8y ago

Terra: C-Like low level language with Lua-based metaprogramming

hasenj
3pts0
www.quora.com 8y ago

EQ, grit, and self esteem are fraudulent concepts

hasenj
1pts0
news.ycombinator.com 8y ago

Ask HN: Would a server written in a native language still need job schedulers?

hasenj
3pts7
kotlinlang.org 9y ago

Kotlin: zero-overhead lambda

hasenj
2pts0
en.rocketnews24.com 11y ago

Steamy shoujo manga illustrations on the importance of strong passwords

hasenj
13pts0
blog.8thlight.com 11y ago

Your code should get *better* with time

hasenj
1pts0
dev.hasenj.org 11y ago

Tools for Front End development

hasenj
1pts0
fontello.com 13y ago

Fontello - icon fonts generator

hasenj
1pts0
dev.hasenj.org 13y ago

A comparison between Backbone.js and Knockout.js

hasenj
2pts0
dev.hasenj.org 13y ago

Why I think Node.JS is a terrible platform

hasenj
100pts141
dev.hasenj.org 13y ago

Why I'm choosing CouchDB

hasenj
2pts0
news.ycombinator.com 14y ago

Ask HN: professional gmail alternatives

hasenj
13pts19
news.ycombinator.com 14y ago

Ask HN: is it worth the effort to build (yet another) publishing platform?

hasenj
4pts9
www.alistapart.com 14y ago

Sketching: the Visual Thinking Power Tool

hasenj
1pts0
dev.hasenj.org 14y ago

Sketching helped me avoid getting stuck

hasenj
5pts0
oud.hasenj.org 14y ago

HTML5 music keyboard

hasenj
7pts0
news.ycombinator.com 15y ago

Ask HN: interesting events/conferences in Sillicon Valley during June?

hasenj
4pts1
dev.hasenj.org 15y ago

What you need to know about music to write a music keyboard app

hasenj
1pts0
www.yuiblog.com 15y ago

Crockford on server-side Javascript

hasenj
2pts0
howsecureismypassword.net 15y ago

How secure is my password?

hasenj
10pts22
www.cs.utexas.edu 15y ago

E.W.Dijkstra: On the foolishness of "natural language programming"

hasenj
119pts69
raphaelhertzog.com 15y ago

Why a Debian package is more than a simple file archive

hasenj
1pts0
seahorsepip.deviantart.com 15y ago

eFirefox theme

hasenj
1pts0
github.com 15y ago

Greenpois0n on github

hasenj
1pts1
www.youtube.com 15y ago

SICP - Layers of language

hasenj
2pts0
news.ycombinator.com 15y ago

Ask HN: Is Facebook benefiting from a ponzi scheme? a bubble?

hasenj
40pts57
news.ycombinator.com 15y ago

Ask HN: Picking a name for your product/company

hasenj
2pts2
www.omgubuntu.co.uk 15y ago

‘Sponsor an app’ model coming to Ubuntu Software Centre in 11.04

hasenj
2pts0
www.omgubuntu.co.uk 15y ago

Mark Shuttleworth announces Ubuntu 11.04 will use desktop version Unity

hasenj
74pts48
www.omgubuntu.co.uk 15y ago

Ubuntu 11.04 to ship Unity as default desktop?

hasenj
2pts0

It's actually quite easy to understand, given a sufficient understanding of human nature.

You're trying to dominate a social situation, because you think you are right (and by extensions, that there are others who will support you and strengthen your position) and because there's a lack of physical threat.

In the real world, you would not want to cause a ruckus, because there could be consequences, and your are not the dominant member of the group. For example; someone could punch you.

If you could, you would want to dominate any situation that you can. We are wired that way.

eh, this is like an obese man complaining that thin women don't want to date him, then when people point out the obvious, he complains why is the onus being pushed on him instead of on the thin women who don't find him attractive.

Fearmongering? That's a strange choice of words.

Do you have profiler data showing that the microseconds needed to pass a message between a process is a significant limiting factor

What? I think you didn't get my point. Let me try again.

You can look at a single operation and say "oh, that's nothing, it's so cheap, it only takes a millisecond". Even though there's a way to do the same thing that takes much less time.

So this kind of measurement gives you a rational to do things the "wrong" way or shall we saw the "slow" way because you deem it insignificant.

Now imagine that everything the computer is built that way.

Layers upon layers of abstractions.

Each layer made thousands of decisions with the same mindset.

The mindset of sacrificing performance because "well it's easier for me this way".

And it's exactly because of this mindset.

Now you have a super computer that's doing busy work all the time. You think every program on your machine would start instantly because the hardware is so advanced, but nothing acts this way. Everything is still slow.

This is not really fear mongering, this is basically the state of software today. _Most_ software runs very slow, without actually doing that much.

What I find more surprising is the length they went through to make git work for them.

It would probably have been better if they had assigned a team of highly skilled engineers to design a distributed source control from scratch specifically to solve the problems faced by the windows team.

After all, `git` itself was developed for Linux because Linus was not satisfied with any of the existing solutions.

The other day I was listening to a clip from Jordan Peterson, and he said something that I found a bit surprising/shocking, but this articles seems to confirm it: people on the left who claim to side with the poor don't actually care about the poor, they just hate the rich.

This article is basically just hating on the rich people.

I think it's rather easy to understand what this author is puzzled by: people want to keep their money. If you've earned your money and you want to keep it, I can empathize with you. If you think you deserve to take other people's money, I can't empathize with you.

I'm sorry but if you have crippling anxiety that you cannot chat about subjects you find interesting then you're going to be a burden on any team.

Selecting only based on chattiness is not good, but filtering out people who cannot even chat is probably a good thing from a company's point of view.

What is behavioral test? Like, I don't understand all these weird paradigms that people come up with to deal with the deficiencies of dynamic typing.

If declaring structs is seen as costly overhead that complicates coding, tests are when more cumbersome.

I really haven't seen much benefit in static typing in regards to software defect rate or quality

Hold it right there. I've never seen anyone argue that static type systems prevent bugs.

I mean they do prevent silly bugs that occur from mistyping variable/property names but I've never seen anyone claim that they eliminate other classes of bugs.

The biggest benefit of static type checking is you know what all the variables are.

    def checkout_cart(customer, payment_methods, cart, session):
        # body
What the hell is customer? What is payment methods? What fields are available on these objects? What methods can you call on them? no freaking idea.

Of course, this kind of code is confusing in Java as well, but for a different reason: Java conventions encourage a kind of obtuse programming style where everything is hidden behind layers of abstractions of factories and managers, so that even when everything is typed, you're not sure what anything is doing because all the data that matters is private and so are all the methods that actually do anything useful. All you're left with is an abstract interface that can sometimes be just as bad as an untyped variable. But this is mostly a cultural problem. (I've digressed).

Static typing make auto complete and refactoring tools easier, for sure, but it also slows down ease of experimentation

Java slows down ease of experimentation because it requires tons of boilerplate code for even the simplest tasks.

It's not the static type checking.

If anything, static type checking helps experimentation because you can change your mind quickly and the compiler will help you catch all the stupid mistakes that can occur from mismatching types or mistyping variable names. This removes a huge cognitive tax and makes programming more enjoyable. Although I will concede this is subjective.

There's no evidence than any of this is true.

First market is not often the winner. Facebook came very late to the social media scene but it dominated.

Google came very late to the search engine scene, and people don't even remember this but there was a time when there were a ton of search engines and anyone at the time would probably think that the search engine market is saturated and there's no space for a new product.

All evidence actually points to better products dominating the market even if they come late.

If your competitors released their app 4 months ahead of you but it was full of bugs and always hangs up, and then you release your product which actually works and performs well, people will see your product as a breath of fresh air.

Another example is the Chrome browser, which came at a time when Firefox and IE were competing fiercely for market share, and Chrome completely dominated them on the simple basis that it was _really fast_.

For most products it doesn't even cost 6 months to make it fast. If you have that as a goal from the very start, there will never be a stage of "omg it's really slow let's try to make it a bit faster". It will always just be fast.

This quote is so misunderstood and so abused all the time.

The point of the statement is to not micro-optimize this and that corner of the program without having any data to guide you on what you should optimize and how.

It's not a rallying call to forgo all concerns about application performance and efficiency.

The mis-application of this quote is the root of all evil in modern software IMO.

It's why a chat program takes 500MB of RAM and why many programs take 10 seconds to load even though there's no technical reason they cannot startup instantly.

You should make it right and fast from the very start. You should not make something that "works" but is full of bugs and slow as hell. Like, that makes no sense at all. If it's full of bugs then it doesn't work. If it's slow as hell then it doesn't work.

1. Make it work correctly and efficiently (to a reasonable degree)

2. Make it even faster

3. Make it better

No I think what we are seeing is a lot more hybrid systems.

I'm not sure why you started that sentence with "No". I actually agree with it.

There are many good ideas that have emerged separately in different languages, and are being combined in some of the new languages.

All I'm saying is, successful upcoming languages will probably be more statically typed than dynamically typed.

In other words, the dynamic typing paradigm is failing the real world test.

Go is like a statically typed language with lots of dynamic features.

Go is statically typed.

The part that lacks static typing (no generics) is the worst part of the language that gets the most flak.

Traditional statically typed OOP languages such as Java is what people want to get away from.

Java's problem is that it's just way too verbose.

    User user = new User(....); // This is not even that verbose

    // Maybe more like this:

    User user = new User(new UserProfile(....), UserManagerFactory.getDefaultUserManager());
People have misdiagnosed the problem and thought it was the static typing.

It turns out to be the lack of support for functions as objects. So for many things you end up having to create dummy classes and objects just to wrap functions.

Even C supported passing function pointers around.

So in this regard, Java is less expressive than C.

Somewhat off topic but I think that more and more people are learning (the hard way, unfortunately) how important static typing is, and how dynamic typing makes it very difficult to develop and maintain large projects.

I think the next generation of successful languages will all be statically typed (whether they will run natively or in a virtual machine is a different (even if related) question).

No necessarily competent. It could be that they are well read on the subject but have no practical experience in it. So they seem able to converse in the subject's vocabulary but if they were to sit down and try to make something they would fail.

That's a common attitude, I was just pointing out how it puts the "passionate" part under doubt.

I've noticed the word "passionate" gets thrown around a lot cheaply.

It's seriously starting to lose all meaning.

And all the code pens are also slow. Between clicking the "run" button and the actual script running there's somewhat of a 3 second gap.

Which kind of puts the opening paragraph into question:

I’m passionate about image performance optimisation and making images load fast on the web.

Like, ok, why aren't you using a simpler blog engine to post? As a plus, if you were in control of everything on the page, you wouldn't even need to use codepen; just include the javascript directly in your page.