Racket gets a mention in https://news.ycombinator.com/item?id=30485604\|https://news.ycombinator.com/item?id=30485604
> Note that I already have that using Racket with a bunch of macros but in my business it is easier to introduce your own language than use Racket…
> > tluyben2 2 hours ago | root | parent | next [–] > > Most people are allergic for lisp likes. Not sure why but it has since always been blocked. I even did a lispy but with <> instead 20 years ago and that was OK (it was the xml for everything hype) while with () it was rejected. I had a talk with the cto of one of our bigger infra structure partners and he had exactly the same issue, so he replaced the () with [] and suddenly it was fine. So he has had scheme in their products for over 10 years but with [] because people are allergic to ().
Could this be related to people strongly expecting prefix () to be for grouping (by contrast to foo(…) ), and the resulting cognitive conflict is hard to resolve?
It’s the best hypothesis I have heard.
I dunno.. I think the world generally rejected XML, too. HTML is still in use “just because” the idea of replacing it would be a monumental task. But I haven’t read about anyone who loves using XML for pretty much anything. Is it still used for stuff? Sure. But anyone who can uses any other format available to them.
I’ve heard people say they love XML due to the tree structure and the generality you get out of it with little syntax. People who would only program in C and JS
I love lisp and its derivatives. I love Forth and its derivatives. And there will always be a place in my heart for Smalltalk.
Forth suffers the masses because anything more complicated than single-parameter threading can be insanely difficult to follow. Quite often Perl is more readable than Forth code.
Smalltalk suffers because - in general - OOP “lost” for two reasons: class hierarchies becoming unwieldy and difficult to manage long-term (is an Mech a subclass of Vehicle or Humanoid?) and due to memory storage it absolutely cannot compete WRT multi-threading and cache coherency.
Lisp - ignoring the whole “Lisp Curse” - suffers in two main areas (IMHO):
- Mathematical expressions are a pain to write and read. I don’t care what anyone says; they are unnatural. Same as Forth.
- Structure and variable assignment/mutation is also equally frustrating. Compare
player.pos.x += dt * speed.xto…(set-vector-x! (object-pos player) (+ (vector-x (object-pos player)) (* dt (vector-x speed))))It’s not the parenthesis, but the baggage that goes along with it. Give the world a Lisp with.notation (or equiv.) and a straight-forward way to write mathematical expressions, and I believe a world of people will find themselves giving it a go much easier.
. is great to have, and Racket can support it via read-cdot. Even with the default reader, the macro system can also kinda simulate it — see syntax-parse’s syntax class.
As a concrete example for structs: https://github.com/Metaxal/bazaar/blob/master/struct.rkt#L153 (needs refinement but you get the point)
In Sketching you can actually write:
#lang sketching
(no-gui)
(struct player (pos))
(define hero (player (vector 0 0)))
(+= hero.pos.x 10)
hero The result is: (player '#(10 0))
I know everyone means well, but the responses are indicative of the problem. “Use macros to solve the frustration” or “Lisp is powerful enough to modify the reader to do that” - while very true - are not programming 101 level stuff for any language.
Either the barrier of entry needs to be very low (it literally needs to be the default implementation) or the advantages need to massively outweigh the initial cost and suffering.
Official support for dot notation and l-values in #lang racket would be nice.
The tension is of course between dynamic/static resolution of id.field where Racket/Scheme usually defaults to a static view point.
I agree, and that’s why I think Rhombus is heading in the right direction, to support infix math operators and dot notation by default.
It’s akin the Linux community responding to trivial things like “how does a user modify their PATH environment variable?” with “Step 1. open a terminal, figure out which shell you’re running, then use vi to edit the dot file…”
Like WTF? :slightly_smiling_face:
> I think Rhombus is heading in the right direction… I haven’t looked at it much at all. I need to, I think.
In the mean time:
#lang sketching
(no-gui)
(struct player (pos))
(define hero (player (vector 0 0)))
(+= hero.pos.x 10)
hero gives (player '#(10 0))
oh nice!
That’s not Racket/Scheme’s vector, right? It means vector that has x and y instead?
To be clearer, I do agree with your assessment in particular for dot and structs (although I have my reserves for infix math) and the fact that it’s not standard hence not well supported and obscured. (Also, I wasn’t really offering a drop-in solution by contrast to @soegaard2)
The nice thing with Racket though it’s that it’s still doable, by contrast to most other languages.
And I really wish a dot notation for structs was standard by default.
It’s the standard vector. It’s not pretty - but if id has no associated “dot fields” then x, y and z is interpreted as 0, 1 and 2. So hero.pos.x becomes (#%ref hero.pos 0). Since hero.pos evaluates to a vector we get the first coordinate of hero.pos.
An effort has been made to make the lookup fast, but it’s of course slower than writing (vector-ref (player-pos hero) 0).
The second reference to hero.pos.x ought to be faster than the first reference.
But I am sure the mechanism can be improved. https://github.com/soegaard/sketching/blob/main/sketching-lib/sketching/dot-method.rkt#L234
The last link shows fake “methods” for vectors: #lang sketching
(no-gui)
(define v (vector 11 12 13))
v.length
(v.ref 1) The result is: 3
12
Sexp is not suitable for handwriting. Imagine that boss asks you to write pseudocode on a blackboard, and you have to count parentheses.
What’s the problem with that? “imagine that you have to write pseudo code on the blackboard and you have to trace vertical lines to keep track of indentation” applies just as well to Python. Also my boss will want math, not pseudocode :smile:
But more importantly, I was trying to find a reason why people seemed okay with prefix notation using <...> or [...] but not using (...) as described in the posts above mine
I personally rather (...) than [...] or <...>.:wink:
@massung Which Forth derivatives do you love/like or would suggest having a look at?
I’ve used a lot of VFX and SwiftForth in production, but for hardware (not desktop apps). I like playing around with Factor at times.
Thanks! I remember having checked the websites for VFX and SwiftForth recently, but didn’t want to spend the money since I’m not even sure how much I’d use them. If you use these compilers in a commercial context, this makes much more sense. Factor is actually what I heard most about; I guess it’s the most well-known Forth-like language. I had looked at gforth, but as I understand it, the GPL would require that all software based on gforth that I publish would have to be GPLed, too.
Actually, most of the limitations wouldn’t be a problem for the start, but they might be if I decide to use a tool written in my free time in a commercial project.
One thing I noticed for me personally is that nested brackets of the same kind (like in ")))") seem to “blur” into each other, even if the font technically doesn’t use kerning. It’s worse with ">>>" (in most fonts), and better with "]]]", where there’s no visual overlap. Still, square brackets can be a bit annoying if there’s too little space between them.
I assume what people deters from brackets in Lisp aren’t their numbers, but that they can appear in big clusters, like in "))))))))".
> “imagine that you have to write pseudo code on the blackboard and you have to trace vertical lines to keep track of indentation” applies just as well to Python. In my experience, it’s much easier to keep track of the indentation in Python than of the brackets in Lisp. That said, if the indentation for Lisp conveys the structure well enough, there’s not such a strong need to get the brackets to balance on a blackboard or whiteboard. Then again, if the Lisp code on the board is part of a lecture on programming, the code should better be correct. :smile: