Hacker Newsnew | past | comments | ask | show | jobs | submit | more TwentyPosts's commentslogin

I had some issues with this very early when I got mine, but I think this went away completely. I feel like this was a software issue, and is now fixed (well, at least part of it).


I think the much rounder corners, as well as the round camera bulge look terrible. These were significantly better in the previous iterations.


Which Pixel was that? I'm really happy with mine (7a)


This like a bad idea on the first glance? Maybe I don't get the whole pitch here?

It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call. The laziness might be interesting, but I feel like "lazy strings" might be all that's needed here. Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.


> It just doesn't seem worth it to define a whole new thing just to abstract over a format() function call.

That could also be leveraged at f-strings themselves.

> Laziness and validation (or custom string formatting logic) are separate concerns and should be separated.

In which case the one to move out is the laziness not the customised interpolation. Because the latter is the one that's necessary for safer dynamic SQL or HTML or whatever.


Hmmm, these are kind of boring? I've seen colored comments a few times, embedding images is also possible in Dr Racket and on TempleOS I'm pretty sure.

Where's all the fun stuff? Debugger features are neat, but outside of this these features just seem tiny and cute and not too exciting.

Even stronger support for structured Treesitter-based editing? (See eg. Helix), proper multicursor support (Helix), both already seem like black magic to me compared to what came before.


What do you do with proper multicursor?

I frequently use it when I need to make some structural changes to consistent code (block replace function name x, add trailing commas, etc). Not sure what more power I am missing.


One of the most powerful features of eg Helix is the ability to very smoothly and easily filter inside your existing selections, or to split them.

I think the focus here is on "selections", as opposed to just "cursors".

So for example, you can select all occurrences of X (say, usage of some global variable), then say "for each of these selections, select the whole function", and then say "select the name of the function".

And bam, this is a (somewhat artificial and forced example), but you assembled a list of all functions with a specific property in a few button presses without ever leaving your editor. This is very close to stuff I do all the time in Helix. This is a godsend when it comes to manipulating (for example) a huge array of JSON data.

Maybe this is all obvious to you, but this seems like the kind of thing that probably still feels like black magic to a lot of programmers, and which certainly hasn't reached all editors yet (most are not focusing on selection editing as a first-class usecase).


Wait, Apple releases papers? Do they have a name for their internal research division? When I think of companies doing AI research my mind generally jumps to Google DeepMind, I didn't know Apple releases any proper research papers at all.


Fun fact: Their first paper, Improving the Realism of Synthetic Images (2017; https://machinelearning.apple.com/research/gan), strongly hints at eye and hand tracking for the Apple Vision Pro released 5 years later.



I believe it, I'm just surprised that I never thought of Apple as a big player here, and I'm wondering if this is an image problem on their side (rare, I know) or something else.


Apple doesn’t like highlighting research or open source contributions in their marketing , likely because people speculate on what it means for products.

There’s a ton of stuff out there from them that they intentionally appear to downplay because of that fear.

Some of it is warranted though. Any little thing gets hundreds of speculative articles written and it’s hard to control a brand.



And a number of them are actually quite good. Sometimes they even release the source for replication


I feel like a link to a 'pitch' or description of the Rhombus language would've been more insightful for most of us. Even being familiar with Racket, I don't know what Rhombus is.


Agreed.

Here's the link I found more informative:

https://docs.racket-lang.org/rhombus/index.html


I didn't. Still not a single explanation of what the language is / what its designers are trying to do.


The OOPSLA paper is more interesting: https://dl.acm.org/doi/pdf/10.1145/3622818

Abstract: Rhombus is a new language that is built on Racket. It offers the same kind of language extensibility as Racket itself, but using conventional (infix) notation. Although Rhombus is far from the first language to support Lisp-style macros without Lisp-style parentheses, Rhombus offers a novel synthesis of macro technology that is practical and expressive. A key element is the use of multiple binding spaces for context-specific sublanguages. For example, expressions and pattern-matching forms can use the same operators with different meanings and without creating conflicts. Context-sensitive bindings, in turn, facilitate a language design that reduces the notational distance between the core language and macro facilities. For example, repetitions can be defined and used in binding and expression contexts generally, which enables a smoother transition from programming to metaprogramming. Finally, since handling static information (such as types) is also a necessary part of growing macros beyond Lisp, Rhombus includes support in its expansion protocol for communicating static information among bindings and expressions. The Rhombus implementation demonstrates that all of these pieces can work together in a coherent and user-friendly language.



Also not sure. I'm guessing it's some kind of Lisp bracketectomy - i.e. Lisp without the parentheses.


Yes. It's a bracketectomy on Racket that's designed to (unlike previous bracketectomies) retain all the metaprogramming goodness of Lisp.


Parens-less(er) Lisp, whitespace/indentation-based s-expressions.


Looks like "yet another Lisp without s-exprs for babby ducks". I'd probably go the Julia route if this is what I wanted, personally.


You are being down-voted for the snark, but there is point there. This seems to be "people use Python because of the whitespace, so let's remove parenthesis." Which if true, is (1) vastly missing the point, and (2) this project isn't really exploring any fundamentally new areas of language design then.

I was kinda hoping to see this was the next generation of Lisp language design, but it appears to be just a different syntax.


> I was kinda hoping to see this was the next generation of Lisp language design, but it appears to be just a different syntax.

Dig deeper in the reference documentation.


It does things Lisp doesn't do?


I a not sure which Lisp you are thinking of, but compared to a "standard" Lisp you might be interested in how the module system interacts with the macro system. In particular the concept of a tower of phases.


Thanks, I'll look into that!


Is that the "Racket 2" thing they wanted to make some time ago?


Yes


The pitch, compared to Racket, is conventional yet still extensible syntax.


I'll have to read about why they made the choices they made, but it reminds me of going to a microbrewery: You tell them you like simple (American) macrobrews, and they say they have just the thing. What arrives is a light lager that tastes awful because they think macrobrews beers are awful. So they made an awful beer that doesn't taste like a macrobrew.

I don't think Rhombus is going to appeal to people that are comfortable with Python, C, Java, Go, JavaScript, etc... It's got infix, but it's cryptic. It seems like a step back from StandardML or Ocaml.

Maybe there's a justification in terms of how the macros work. Maybe they're poisoning the well to make Lisp syntax more appealing. I'll try to reserve judgment, but so far I'd rather program in Scheme/Racket than this.


I don't think the Racket/Rhombus developers are really trying for adoption. They're trying to push the field forward via their research. Creating these useful programming languages is how they validate their research, but the end goal is not to grab a large share of working developers but to grab mindshare of the few developers who create the future of programming. In this they have been quite successful.


I agree they probably aren't going for world domination, but here is a nice video from Mathew Flatt where he says, "The point of Rhombus is to make Racket macro technology more accessible" and "removing an obstacle for most people":

https://youtu.be/OLgEL4esYU0

Having traditional infix operators, function calls, array subscript, and field access is a great start, but after that it doesn't look very traditional or familiar at all.

I hope they succeed, and I'll keep following their progress, but when I look at their if-statements, it's pretty non-traditional:

    if is_rotten(apple)
    | get_another()
    | take_bite()
      be_happy()
It looks like it has indentation-based grouping with vertical bars, white space, and colons implying different precedence, and that makes me have a lot more questions. I think my American macrobrew analogy above holds.

https://docs.racket-lang.org/rhombus/Notation.html


(I'm not very involved with the Rhombus project. I just post there a comment from time to time.)

I think that the macro system can handle the traditional "if X ... else ..." structure, but there is a design decision to avoid magic keywords like "else" as much as possible, like "in" in "fox X in Y: ..." Why should each construction have a different magic keyword? Can it be solved with only one thing that is shared in all construction like "|"? If you see the examples, all the other constructions with branches like "cond" that replaces "if" with "elseif" or "elif" ir whatever use "|". "match" also uses "|". This is better if you want to write macros that extend the language and have a similar structure.

(For what it's worth, I insisted in that "if" uses two "|" (one for each branch, instead of one only for the "else" part.)


> one for each branch, instead of one only for the "else" part

aut consequens, aut alternatus? ( https://en.wiktionary.org/wiki/aut#Conjunction )


Yeah, the if statements are definitely a little weird-looking to me. It seems like the goal is to allow for more traditional infix syntax while still defining most of the language using the macro system; it seems unfortunate if their macro system can't handle more traditional-looking "if (x} block; else block" conditional statements.


As someone who gets the shakes from looking at too many parenthesis I think it's a great step in the right direction.

A few weeks ago I went through the "GUI demo" source, and it's not bad. Of course just reading it doesn't tell much about what's the IDE support, how easy it is to figure out the arguments/types. (But it's rhombus/static, which is encouraging!)

https://github.com/racket/rhombus/blob/master/gui_demo.rhm


a.k.a. Python-like with macros


It would also help to have such a description in the README


They have an attack which stuns the player, followed up by a grab attack which looks a lot like them trying to bite(?) your head across a few seconds, doing immense damage.

I think it's probably intended to be that, yes.


Yes, pi has an infinitely long decimal expansion, and there are infinitely many prime numbers.

No deep messages have been found in either yet, and I am sure some people tried, so it stands to reason that no such messages exist. Mathematical objects can be complicated and difficult to understand and go on for infinitely long without having secret messages hidden in them.


Of course they can, and with an infinitely powerful machine it would be cheap to check.


Andrew (in the linked Github page) answered a question as follows:

> Question: "So after this change, is there way I can still simply call zig run or do I have to use a build.zig file?"

Andrew's answer: "No, this use case will regress."

This in fact literally states that "just" calling "zig run" won't be possible anymore, and heavily implies you'll need a build.zig file.


After some more recent comments,

> This in fact literally states that "just" calling "zig run" won't be possible anymore,

This seems correct.

> and heavily implies you'll need a build.zig file.

This seems to not be the case.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: