HNHacker News
TopNewBestAskShowJobs

rkido

341 karma · joined March 31, 2017

submissionscomments
rkido··on Why you should learn F#
I believe this class-oriented workaround is a side-effect of Don Syme's decision to strip out the OCaml module system from F#.
rkido··on Thelio – System76
Every single binary that works on Ubuntu will work without modification on Pop!_OS.

That is not true for Debian. Some packages (like the .deb file for Chrome or VSCode) should work on any distribution that supports dpkg, but there are many packages that break compatibility between Ubuntu and Debian. Thus Ubuntu isn't just a customized Debian; it's a customization that creates a distinct operating system.

rkido··on Thelio – System76
This looks cool. But why do they keep marketing Pop!_OS as a different operating system? This is confusing to people who don't realize that it's literally just a customized Ubuntu.
rkido··on Deep learning experiments in OCaml
Not all function-oriented languages use static binding. Due to how the BEAM VM works, Elixir/Erlang is very, very function-oriented but also late-bound. Nevertheless, its type system is relatively rich compared to most other late-bound languages.

It's never static binding that makes a language good or interesting, apart from performance benefits. You can get the productivity boon of early-warning type-checking with or without it. What makes a language good, in my opinion, is its ability to provide a type system that closely matches the needs of the domain in which that language is to be used. For example, game development requires a data-oriented approach, which Rust's type system practically forces the developer to adopt.

More complex software engineering problems require more expressive type systems. But unless you're the one writing TensorFlow, machine learning is insignificant from a systems engineering perspective; it's simple enough for non-programmers. Thus, expressive type systems don't seem to offer much benefit here.

rkido··on The Unreasonable Effectiveness of Dynamic Typing for Practical Programs [video]
I'm no expert on type systems so my definitions are not meant to be theoretically correct, just to describe the practical implications of static and dynamic typing.

What you're talking about seems to be more related to how type systems are implemented, i.e. that dynamically-typed languages are "unityped", such as the one and only "static type" of Python being the PyObject. Thus, when you "bind an unassigned variable and then assign a value later", you're actually implicitly declaring the type to be PyObject.

But it is deceptive to define type systems purely in terms of this implementation detail, because then it would appear as if dynamically-typed languages are untyped (i.e. "everything is one type" is the same as saying "there are no types"). Since we know languages like Python do some type-checking at run-time despite everything being a PyObject, it is more useful, I think, to think of these languages in terms of the practical result rather than in terms of the implementation.

But if that's not what you're saying, I apologize.

rkido··on Higher Education Erodes
The purpose of higher education isn't to educate the mob. It's to protect education -- the very notion of being educated -- from the mob.

That so few schools recognize this doesn't mean "higher education is eroding"; higher education has always been a niche of a niche.

rkido··on [dead]
Geniuses are made, not born. It is entirely within the realm to achieve something like this with the proper training. See "Peak: Secrets from the New Science of Expertise".
rkido··on The Unreasonable Effectiveness of Dynamic Typing for Practical Programs [video]
> Static typing requests you to explicitly declare types.

You are confusing explicit typing with static typing. "Static" means "compile-time checking". "Dynamic" means "defer checks to run-time". Some language implementations can disable run-time type checking if optional type annotations are added, such as in Typed Racket.

In other words, all the following combinations are possible:

  - Implicit + dynamic + strong: Python
  - Implicit + dynamic + weak: JavaScript
  - Implicit + static + strong: Standard ML without type annotations
  - Explicit + dynamic + strong: Elixir with type annotations
  - Explicit + static + strong: Java
  - Explicit + static + weak: C
I struggle to come up with examples for these...

  - Implicit + static + weak
  - Explicit + dynamic + weak
... but I'm sure they exist, perhaps as historical languages from when type systems were less sophisticated. After all, "strong" and "weak" are entirely relative, constantly in flux, and exist on a continuum. In a couple decades, anything lacking dependent types might perhaps be considered "weakly typed".
rkido··on China's New Wave of Internet Censorship: Name Verification for Online Commenting
Try using WeChat every day for a few months and then tell me again they're not leading the pack. I don't even use it in China (where it's power is significantly higher than everywhere else), yet even ignoring features that only work in China, it is by far the most powerful messaging client currently available.
rkido··on China's New Wave of Internet Censorship: Name Verification for Online Commenting
Um, you seem to be unaware of Tencent and Alibaba, both vast enterprises. Tencent owns League of Legends, the biggest multiplayer game in the world, as well as WeChat, which is comparable to WhatsApp in number of users. WeChat is revered by tech leaders in the West, it basically blows everything else out of the water in terms of features and robustness.
rkido··on Ask HN: What do you want to see in Ubuntu 17.10?
- FLAVOR: Ubuntu Desktop

- HEADLINE: Faster Dash

- DESCRIPTION: I still use Ubuntu Unity because of the superior UX of app indicators, which GNOME refused to merge many years ago and still sucks to this day for it. However, one thing I miss a lot from GNOME is the far snappier application search/launcher.

The Unity Dash has some pretty poor ergonomics overall compared to GNOME's "Activities", but that is not what I'm concerned about right now. All I want is for the process of (1) pressing Super (or the "Windows key"); (2) searching for an application; and (3) launching the application I searched for to go at least as fast as it does in GNOME 3. Right now I use the crash-prone Synapse[0] instead of the Dash.

You might be wondering: "But isn't it really just as fast?" First of all, no, sometimes the Dash itself opens really slowly for no apparent reason; and second, strictly speaking, it's not the speed of opening an application that is problematic; it's the slow feedback loop of getting search results as you type. This feedback is instantaneous in Synapse, near-instantaneous in GNOME Shell, and comparatively slow as heck in Unity Dash. Disabling the extra features in the Dash helps a bit.

It's also very annoying that it doesn't automatically highlight the first search result (as it does in GNOME), which makes it ambiguous as to what will happen when you press Enter.

And it is awful that in order to select any search result after the first, I either have to: (1) keep typing to narrow the search down further; or (2) move my hand all the way over to the arrow keys, or worse, the mouse.

Pressing TAB doesn't cycle through the search results, it cycles through: (1) the "Applications" UI header; (2) the first result of the "Files & Folders" section (instead of the header -- why the inconsistency?); (3) the "Filter results" button.

I know Unity 8 is the priority these days; even if the Unity 7 Dash can't be fixed, I sure hope Unity 8 doesn't make the same silly UX mistakes.

- ROLE/AFFILIATION: Software developer

[0]: https://launchpad.net/synapse-project

← PreviousPage 2 of 2