HN user

thrwaeasddsaf

108 karma

gone

Posts0
Comments82
View on HN
No posts found.

How's the battery life? Can you replace the battery if/when it gets old?

That looks like something I could buy. I've really wanted a tiny console PC with RS232 and ethernet for a long time now. I thought about building one into a custom keyboard using something like a raspberry pi but I haven't had the time to follow through. This thing looks like it could make my diy project unnecessary.

I also haven't found phones particularly appealing.. mine gets 5-6 days on a charge because it's mostly just an alarm clock. Any time I try to do anything with it, I get frustrated by how clumsy it is compared to an actual computer. I do like being able to look at maps or make a call in an emergency, and it's handy having a camera always in the pocket, but that's pretty much where the appeal ends.

There's also some low-hanging fruit if someone wants to contribute. E.g. the developer docs are rather outdated. I recently implemented AMD FSR as a Gimp plugin but all the docs led to code that resulted in a slew of deprecation warnings. Also poor performance and some thing just not working right at all (tile cache). I kinda got frustrated with it and dropped the gimp parts altogether, but if I had more time, it shouldn't be hard to figure out and maybe improve the docs or write an up to date tutorial.

You could say a human is laundering GPL code if they learned programming from looking at Github repositories.

I don't have photographic memory, so I largely don't memorize code. I learn general techniques, and memorize simple facts such as APIs. I can memorize some short snippets of code, but these probably aren't enough to be copyrightable anyway.

The type of model they use isn't retrieving

How do we know? It think it's very likely that it is largely just retrieving code that it memoized, and doing minor adjustment to make the retrieved pieces fit the context. That wouldn't differ much from finding code that matches the problem (whether on SO or Github), copy pasting the interesting bits, and fixing it until it satisfies the constraints of the surrounding code. It's impressive that AI can do that, but it doesn't sound like it's producing code.

I think the alternative to retrieving would actually require a higher level understanding of the world, and the ability to reason from first principles; that would be much closer to AGI.

For example, if I want to implement a linked list, I'm not going to retrieve an implementation from memory (although given that linked lists are so simple, I probably could). I know what a linked list is and how it works, and therefore I can produce working code from scratch.. for any programming language, even ones for which no prior implementations exist. I doubt co-pilot has anything remotely as advanced as this ability. No, it fully reliant on just retrieving and reshaping a pieces of memoized code; it needs a large corpus of code to memoize before it can do anything at all.

I don't need a large corpus of examples to copy, because I use my ability to reason in conjunction with some memoized general techniques and common APIs in order to produce original code.

Why is is better? It just seems different.

APL's usage of monad predates its use in conjunction with modern functional programming languages, by the way. It goes back to the 60s, and there are plenty of books and papers where these terms are used that way.

https://en.wikipedia.org/wiki/Monad_(functional_programming)...

I can't say I care too much which terms people use, but in context of APL, I prefer the terms that were used by Iverson and have been in print for more than half a century.

Tiny Acquisitions 5 years ago

Is it really or is it just in the SV bubble? Or is this a case of "it's not interesting if it's not in SV"?

Sometimes reading HN gives me the feeling that there is no "tech" other than FAANG in the US. Or somehow every little "tech" company is just making FU money, which sounds hard to believe.

But stack languages generally do evaluate left to right.

I don't see why you couldn't do right to left. Makes no semantic difference.

But the original post has a snippet that should not only be evaluated right to left, but also bottom to top. Unless their indentation implies hidden parens.

I think I’ve heard that the APL semantics is commonly described right to left so might be related?

Not particularly related. It's just that every function is either monadic (operand on the right) or dyadic (infix). That makes it a case of not needing to explicitly specify where the function arguments start and end, still without using a stack; it is purely syntactic, and obvious (although you do need context to parse anything that uses user-defined things). Parentheses are still needed for the left operand of a dyadic function if it is to take an expression more complicated than a plain array.

If you had functions of higher arity, then it would become necessary to add parens, delimiters, or a stack.

I'd be interested in seeing personalized ads but there is no such thing. I recently had a look at what ad categories Google applies to me and honestly.. it is so wide that it is does not feel personal in the slightest, and indeed it's wide & vague and nonspecific enough that "employed male, about 30, western" would be a sufficient description. Indeed, I feel like that just filters for the ads they'd blast on broadcast media all day long anyway.

Advertisers don't really understand who I am or what I want, and Youtube history isn't a good substitute. If anything it's circular, because Youtube also keeps recommending the same shit based on viewing history..

Yeah, all this concern with scalability, portability and clean code, has created quite a dystopian software world.

I don't see it having anything to do with scalability, portability, or clean code.

It's just cheap and (for the developers) convenient. Developers think that their software is a gift to the world, and simply getting it made (not matter how cheaply and craply and user-hostilely) is a net positive. (I wonder how many people use all these bloated things only because they pretty much have to, due to peer pressure, company requirements, etc.)

It is possible to make software that scales, is clean, portable, and doesn't rely on massive bloat.

If you're going that route, I'd focus on small & cheap SBCs. A bare, credit card sized ARM computer is probably going to be more ecological (both in manufacture and operation) than an Intel PC.

Works with any encoding and arbitrary binary data. The last byte of the length field doesn't have the high bit set, and whatever follows after that is completely irrelevant.

But still needless complexity for this.

I haven't seen a tool that can remove fluff and clean code. And I don't like formatters, because making the rules right is too complicated. I haven't seen a formatter that won't eventually mess up code that I carefully laid out.

As always, there's a flipside..

I find code with lots of comments and "fluff" to be a drag to read and navigate and generally work with. I would rather have less to scroll to begin with, than have comments help me jump to a specific spot.

For example, I just replaced a well documented pair of functions that compute a checksum. The original implementation was about thirty lines, including comments and empty lines. My implementation uses a denser style and is just a single function with three lines in the body. I also removed a function argument to make the interface both simpler to use and also less general. KISS & YAGNI: if the more general version is ever needed, then it is trivial to add and make the simple version a wrapper for it. Until a real need shows up, I don't want it.

Of course my changes go way beyond comments, but this kind of thing can make an order-of-magnitude difference in code size (as measured in lines). I would rather work with 300 lines than 3000 lines, and the reduced need for jumping/scrolling around lessens the importance of navigation aids. Also, I find that the aids that are there anyways (function names, etc.) become more useful when there's no fluff to render them ineffective.

You're oversimplifying, because the question isn't about paying to remove ads vs not paying and seeing ads, but about paying and getting the product or not paying and not getting the product.

People's behavior depends on the circumstances they are given, and if "free (with ads)" is one choice, then indeed a lot of people will choose it over paying. However, if option is not given, it doesn't mean everyone who would've picked free are not going to pay at all.

There are some highly popular freemium/ad supported games but also lots of very popular games that you simply must pay for. Applying the 1% number from products where the choice is ad-free-or-paid to must-pay-for games and assuming they'd get 99x more users if given for free with ads is just completely wrong.

In general, people seem quite willing to pay for games (this may be less true in mobile, that's a rather different market). The challenge isn't that people don't want to pay, it's that the market is extremely saturated and it's hard to stand out from the crowd & produce a game that everyone wants to play over all the other choices.

Why is it unfortunate? It's entirely plausible that they've managed to pick the behavior that makes most sense for each operator. Different operators being different, it doesn't make sense to expect all to behave the same. And it would be unfortunate if the common use cases were complicated by having to code out the sensible behavior if the defaults were wrong.

I don't believe that it's just a matter of "getting used to it", there are objective metrics of readability, developer error rates, and speed of training that some languages do poorly at.

If we had such objective metrics on APL or K, that would be an interesting discussion. But what I've seen here is just opinion and anecdote.

I also think that "looks like line noise" is a fair characterization of how J and K look on the surface, but that does not mean they are unreadable.

I'm hardly qualified to give any deep insight, but after reading the first half of Aaron Hsu's thesis and playing around with a Dyalog APL interpreter online for a few days, APL starts to look quite readable to me (much more so than J, thanks to the additional symbols) and I found it rather easy to learn (unlike mathematics, but for me the struggle there is not at all in syntax but in the concepts, methods, and meaning).

Alright. Maybe I just have a hard time seeing past the product, or the marketing is too obtuse for me.

Car ads for example are a complete blur in my head. The only thing that I distinctly remember is when everyone had ads with their cars driving in shallow sea water, which I found absurd. Do they still do that?

I certainly do feel pinned down in life, but I also don't remember seeing ads that offer a concrete solution (and I'm not even convinced its solvable). I don't think I need to be sold the dream to be free, because that is already something I desire very much. I just see products. Ones that will not fulfill that dream.

That's beside the point, I think. What's the dream?

Yes, I might prefer pepsi to coca cola or vice versa and maybe that's a product of marketing, but both are just drinks to me. Just another product. Which I might buy once in a while, but it's really got nothing to do with my dreams.

I don't really understand the point about dreams. Do they sell you dreams? What kind of dreams? I see ads for products and services, most of which do not resonate with me at all. I have my own dreams, and I don't see them having anything to do with marketing.