piano

10 ms·

1.
by piano 7y ago
> because you simply are stating that exponential processes are going to continue. Exponential process continuing doesn't imply "we're going to get there soon" in any way, shape or form. The desired goal can still be
2.
by piano 7y ago
> Well, the alternative is to learn an actual dozen of language I would say that this is actually almost always preferable, for two reasons: 1. I believe it's generally good for programmers to know multiple languages, to be exposed
3.
by piano 7y ago
> - Pure functions: these allow you to statically guarantee that a piece of code doesn't perform any IO and is a completely deterministic function of its inputs. Is this actually true? As far as I know D's pure isn't the s
4.
by piano 7y ago
> but I prefer Go's culture much more To me, Go culture is very arrogant, so much in fact that it almost reminds me of some Lispers of old. Unfortunately similar thing can be said about Rust. However, in Rust, most of the crap seems
5.
by piano 7y ago
> Go is designed to do concurrency via message passing, not shared memory. ... and yet experienced gophers will criticize newcomer's code for using channels too much and they will tell you you need to use traditional stupid shared m
6.
by piano 7y ago
> This article deals with "big picture" aspects Read: It's a rant and/or PR.
7.
by piano 7y ago
> Suppose Bob's codebase has a structure implA that implements interface A, and you want to use in terms of its interface. If the language requires Bob to declare implA as an implementation of A, you have to persuade him to do so i
8.
by piano 7y ago
> The thing I love about Go is its fundamental clarity. It's very upfront and literal. I find it easy to understand what is happening in any particular bit of code. When reading Go codebase I'm not familiar with, I'm very
9.
by piano 8y ago
Yup, and besides, Go has the unsafe ( https://golang.org/pkg/unsafe/ ) package, which allows for basically the same sort of unsafety as Rust's unsafe. In fact, I would say Rust is typically more safe than Go, b
10.
by piano 8y ago
You don't describe what you actually want or consider 'sane'. But the answer is probably "There's no such thing" anyway, unless you're looking for Rust, which you probably aren't.
11.
by piano 8y ago
> The number of stars on GitHub is significant because most people whose opinion you’d care about are on GitHub, they wouldn’t star project that they were not interested in and there aren’t widespread fake accounts. I am on Github and ha
12.
by piano 8y ago
In languages with termination analysis and dependent types, the source code _is_ the proof and it's verified by the compiler. Basically when such a program compiles, it's proved to be correct according to the specification. Of cou
13.
by piano 8y ago
> Sure, you can’t in the general abstract case, but my exact point is that you can do this in practice, for programs which we actually write. No, it can't be done with testing even for practical everyday programs, precisely because
14.
by piano 8y ago
> The previous poster is correct. Software cannot be proven to be bug-free. Yes, it can, that's what the whole formally verified software branch is about. Of course, even with formally verified software, there can be failures caused
15.
by piano 8y ago
I never said people didn't like Spotify or Slack. In fact, I said the exact opposite. Please read the comment properly and try to understand, don't just skim checking for "the right" opinion.
16.
by piano 8y ago
The thing about Electron - and the thing that Electron fanboys either don't realize or don't care - is that with Electron, the company/vendor wins at the expense of users, who have to put up with their "application"
17.
by piano 8y ago
They really should cut the middle man. What surprised me reading that wiki page is that apparently the metric system was opposed in the US based on religious reasons . That is mind-boggling.
18.
by piano 8y ago
> Hey can you give what is the rationale behind the JS hate? JS has its overhead in terms of data and, more severly, performance. Many people tend to put unecessary JS stuff like custom scrolling, needless animations and needless interac
19.
by piano 8y ago
> It's always been surprising to me that their isn't a built in "undo" to `rm` Have a look at either the `trash-cli` package by Andrea Francia.
20.
by piano 8y ago
> But people need to feel productive quickly with a language, otherwise they'll drop it and move to something else which makes them feel that way. Yes, I agree, but that's not the full picture. People want a language in which
21.
by piano 8y ago
> In Rust, if I want to write a similar thing, a HPACK decoder that returns both `io::Error` and `HPACK::DecodeError` for example, I need come up with another `Result` type that wraps both errors. This can sometime be tiring and makes th
22.
by piano 8y ago
> This attitude is fine for personal projects, but it does not scale when working with other people. True, but the same is true of Go, which may be surprising to people. Despite its claims, Go didn't solve this problem. One reason i
23.
by piano 8y ago
This is the n-th time I'm reading a suggestion to help Venezuela using Bitcoin/cryptocurrencies. I wonder whoever came up with this and whether there's any save reasoning behind it or if it's just a cryptonerd fantasy. V
24.
by piano 8y ago
> Consider, however, that you are a computer scientist in 2012 that has been working in the field of image recognition using hand written algorthms for 20 years. You are the best in your field, highly respected. Your code has been refact
25.
by piano 8y ago
I use a terminal text editor when I'm doing something in the terminal, need to do a quick edit and don't want to have to switch away from the terminal into a GUI editor. For me that's typically commit messages and not-too-com
26.
by piano 8y ago
It's not just the interface{} thing that's annoying. From my point of view, Go has way to many annoyances to be decent. No constness. No protection against copying. No compiler warnings. Crap error handling. Public/private de
27.
by piano 8y ago
> But the way I see it, 95%+ of programs don't truly need generics. Yes, they do. Pretty much 100% of programmers in statically-typed language need to use generic types/functions. The "95%+" thing is just an observa
28.
by piano 8y ago
> Go tries to be non-magical, and sadly that can take much of the whimsy out of programming. That's a weird thing to say seeing that Go very much is magical... Slices/arrays are magical and so are maps, channels and channel o
29.
by piano 8y ago
This is the root of the Go confusion. The code will indeed still be easily understandable on a line-by-line basis, but larger units (functions, groups of functions, modules) then become harder to read and understand due to large amounts of
30.
by piano 8y ago
Are you joking / trolling? The article clearly instructs to _avoid_ refleciton...

More ›