Racket Is an Acceptable Python (2019)

https://dustycloud.org/blog/racket-is-an-acceptable-python/

by behnamoh • 4 years ago

181 128 4 years ago

dustycloud.org

phyrex• 4 years ago

(2019)

Labo333• 4 years ago

See a previous thread: https://news.ycombinator.com/item?id=20392448

dang• 4 years ago

Thanks! Macroexpanded:

Racket Is an Acceptable Python - https://news.ycombinator.com/item?id=20392448 - July 2019 (168 comments)

dark-star• 4 years ago

We used Racket in the early 2000's at university, in the first year of CS. Everyone (including me) was appalled by it (we already knew C, Pascal, Java, etc.)

After a few weeks it "clicked", and since then I've been a huge fan of Scheme. When other students went out of their way to write C-to-Scheme converters to keep coding their homework in C, if you fully embraced the language it felt something close to enlightenment ;-)

I used Scheme later to teach programming to absolute non-science people and they all simply "got" how it worked, even though they had previously struggled doing even very basic things in Excel Macros and the like.

Scheme is a perfect tool for learning how to program, and it is even useful later to write complex programs in production. Yes, C might be faster, and Python might have more hits on StackOverflow, but to really understand the concepts behind polymorphism, recursion, lazy evaluation, oop, etc. Scheme helps a lot with it's simple syntax.

agumonkey3• 4 years ago

The surface reduction really helps grasping ideas on many dimensions [0]. Also some scheme impl are probably running circles around python perf.

[0] see python talks about not using classes for single method cases which are just fat closures. Yet it's still often used.

rytill• 4 years ago

Can you share an example of such a talk?

ModernMech• 4 years ago

Also some scheme impl are probably running circles around python perf.

I have an abacus that has better perf than Python, so I’d say this is a safe bet :P

mbrodersen• 4 years ago

Not much of a challenge. Python is super slow when not simply calling C code.

giraffe_lady2• 4 years ago

Racket was also my first exposure to lisp and I recoiled from it as well. Shortly after I ended up working in clojure for a while, which I felt "fixed" a lot of the things I thought I didn't like about racket.

I still think the clojure syntax and immutability semantics are prettier than racket's but that's just my own vanity. I'm back on racket for the reasons mentioned in the article pretty much: good fundamental language, big and practical standard library, plus every freak academic CS thing you could ever want to play with available as well.

The tooling and community also encourage you to think of problems in terms of DSLs, something it partially shares with ruby as well. That approach isn't always a good fit, or one you can get buy-in for, but when it works it works well for me.

zestyping• 4 years ago

This part was counterintuitive for me:

We found the age-old belief that "lisp syntax is just too hard" is simply false; the main thing that most people lack is decent lisp-friendly tooling with a low barrier to entry, and DrRacket provides that.

If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

Are there many people who believe Lisp syntax is as easy as Python or other non-Lisp languages? If that's true for you, I'd be interested in hearing more about your experience.

sigzero• 4 years ago

Racket is up there for something I want to learn so I poke around in it. I don't find the syntax as easy as Python myself.

metroholografix3• 4 years ago

I find it's better to think in terms of "familiar" vs "not familiar" rather than "easy" / "hard". Lisp syntax to me is the easiest -maybe with Forth and Smalltalk- syntax around, certainly orders of magnitude easier than Python's. And I don't mean just semantics, but also conceptual beauty. There's something about it that feels so elegant that other languages do not possess (again with Forth / Smalltalk exceptions). I can take a young curious kid with no previous exposure to programming, and teach Lisp syntax in under 5 minutes.

But a kid with no previous exposure to programming is nothing like your average developer with strong pre-existing conditioning about how programming languages must look like. And this is the issue I feel with a lot of folks complaining about Lisp syntax. It's easy but it's not _familiar_ and some find it harder than others to get used to this discrepancy.

baq2• 4 years ago

as the saying goes, the only intuitive user interface is the nipple.

giraffe_lady2• 4 years ago

I love lisp but there is the practical problem of paren juggling. You either need to come up with and execute by hand a line-break-and-indent system on the spot, or use tooling to manage them.

It's not a huge hurdle and other languages have equivalent problems. But the lisp one is particularly ill-suited to other tools, even visual techniques like manually aligning indents.

I've taught programming to beginners, including lisps, and it's definitely one of the early disorientations even without prior expectations about code. You don't need much: I eventually settled on just giving them sublime with rainbow parens and telling them to hit enter a lot. But you need something and it's not obvious what's missing unless someone points you in the right direction.

lastofus• 4 years ago

After writing Clojure for a few years, there were several times where I ended up with a complex function with unbalanced parens, and the only way I could fix it was to basically re-write the function piece by piece. This is something I've never had to do in any other language.

I'd also end up in not great places when utilizing parinfer while editing code written using different formatting than what parinfer expected. I'd have to fall back to paredit and hope for the best.

This is all to say that yes, sometimes editing lisp syntax is "hard", at least for me. Turns out some humans make so-so AST parsers.

That said, structural editing is great once you get good at it, and something I miss back in other languages.

capn_duck• 4 years ago

I strongly disagree that Lisp syntax is straightforward. Racket/Scheme is decent, but Common Lisp and other Lisp-2's can be incredibly confusing. Having different value and function namespaces for symbols is complicated enough, but the worse problem is that the simple evaluation rules don't always apply.

The base case is simple enough, the symbol-function value of the first symbol in a list is looked up, the rest of the arguments are evaluated or self-evaluated, then passed in to the function. The problem is that when the first symbol is a macro, you need to remember which of the following arguments are evaluated, or taken as unevaluated forms. Anyone who thinks this is easier to parse because there's less syntax either has too little experience with Common Lisp, or is kidding themselves.

JaumeGreen• 4 years ago

If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

Not in this case. Lisp syntax is easy, people lack familiarity.

The only "hard" part is checking that the number of parens are right. But it's not that other programming languages don't have equivalent "hard" problems, like closing the right kind and amount of brackets on C, of whitespace problems in python.

wrycoder4• 4 years ago

If you make an error in the number of closing parens, and hit return, your cursor will end up in an unexpected place. That's the sign you should take a second look at what you just did.

pen2l• 4 years ago

Are there many people who believe Lisp syntax is as easy as Python?

Even with python I find myself getting bogged down by missing a parenthesis here and there around function calls, but perhaps that problem is unique to me and my attention and memory issues. Syntax highlighting in editors is great, and certainly it helps me, but I wish for them to be even more interactive and assertive: it should mark fields with obvious errors like unclosed quotes and parentheses, I shouldn't have to wait after compile or run-time to be informed of these errors.

Aid that reduce syntax errors should always be welcome. Moreover, some of us have high working memory and some don't so I welcome opinionated tools like Spyder IDE and Jupyter that are hands-on in the dev stage, and serve to encourage a fun and exploratory dev environment.

Stratoscope• 4 years ago

it should mark fields with obvious errors like unclosed quotes and parentheses

PyCharm does that and more.

What editor are you currently using?

bklaasen• 4 years ago

Once I got into the habit of typing the corresponding closing entity (quote, paren, backtick, whatever) immediately after typing the opening one, and _then_ coming back to fill in the data in the enclosure, most of my syntax errors disappeared.

It's surprising how many professional devs don't have this habit. I learned it pairing one day.

kbd• 4 years ago

I had little experience with Lisp until recently when I converted a few hundred lines of Lua to Fennel. I have a lot of experience with Python.

I've always been scared of Lisp syntax, but after just a little experience with it it all kind of fades away and it feels like an indentation-based language, while remaining very compact. Now I'm like "why aren't all higher-level languages lisps"?

Editor tooling definitely helps, but it's one of those "skill floor skill ceiling" ideas. Parenthesis-based syntax has a slightly higher "skill floor" (takes more effort to edit), but with editor tooling has a much higher "skill ceiling", where experts can move blocks at the level of syntax rather than characters. Even just vscode's new bracket highlighting and guides are a small feature but a big help to see structure.

anon_123g987• 4 years ago

Syntax can be simple or complex, and - independently - easy or hard.

IMO Lisp's is hard, but simple; Python's is hard and complex.

Tooling can make it easier (keeping track of parentheses and significant whitespace, respectively), but not simpler.

kazinator14• 4 years ago

I've done all my Common Lisp programming in Vim.

The TXR language was developed using nothing but Vim, for all the C and Lisp code.

The tooling is the same as for C: indentation, coloring, parenthesis matching, and that's more than you need.

E.g. visually select some code with V and cursor movement, then hit =, and it's nicely reindented.

Vim's Lisp indentation is based on the classic Vi ':set lisp' mode which was in Unix since 1980 something. That is combined with some generic autoindent settings, most of which are pretty much the same as for C.

GNU mkid (from the id-utils project) indexes Lisp like other languages for quickly finding all references to an identifier.

Exuberant Ctags recognizes Lisp files, for jump-to-definition.

People who talk about special tooling for Lisp must be coming from the perspective of Nano or Notepad.

Or else from the perspective of "any programming editor which is not the one I know is 'special tooling', and the one I know doesn't recognize any Lisp file suffixes."

petre• 4 years ago

No, the syntax is easy. Aligning the paranthesis is the annoying part where the tooling comes in.

kazinator14• 4 years ago

If the syntax requires special tooling to make it usable

It doesn't. Lisp is perfectly editable in Vim, with basic indentation and syntax highlighting. Lisp's properties make it easy to work with even in that type of basic editor without special Lisp support.

Exuberant ctags indexes Lisp code for jump to definition.

kkfx2• 4 years ago

I believe lisp is easier than python in usage, but ONLY after you learned it. That might sound a bit strange but it's a classic issue most people ignore: ecosystem.

Python is "battery included" in the sense that with the language it's users can access a rich set of ready-usable code pip-able in a venv without any special gimmick and python itself is probably preinstalled in most desktops people who ever write a line of code use, that means python is not a stranger, it's a citizen of a familiar and ready made ecosystem for most users.

Lisp on contrary have many flavors, syntax is similar, but here is (defn, here (defun, ... and CL is still complex and not such immediate. QuickLisp is not here by default etc. Lisp is a stranger in most user's familiar ecosystem.

Non only Lisp is from a civilized age where computer were desktops, a unique ecosystem at the users fingertips, centered on users needs and desire. In that sense lisp is an ecosystem, not a part of a larger ecosystem the user already know. Again a stranger.

Once you know a bit let's say SBCL or Emacs it's far easier implementing something that do not demand something ready-made and absent (the aforementioned battery included) BUT if nobody teach them and only very few know them...

I say that fly a small plane is easier than drive a car, but while I do both things most people do not and so for them I say something alien and the subject of the topic is also alien to them. Most think that's easier turning the steering wheel obtaining a definite result instead of gently hit a stick to see loose effects. Of course that's true, if you are bound to a little path named a road, more specifically a small part of it, however it's far easier NOT being bound to such small areas and loosely move in the air, with far less strict limits all around. You have to try to understand though and so someone have to tech you up front... That's the modern Lisp issue...

bsder• 4 years ago

Of course that's true, if you are bound to a little path named a road, more specifically a small part of it, however it's far easier NOT being bound to such small areas and loosely move in the air, with far less strict limits all around.

That's a very interesting observation. It's also interesting in that when you get back to "high traffic" areas where you have to interact with others, the limits get stricter again.

I'll probably torture that analogy for a while.

mtreis86• 4 years ago

I really like this analogy.

gus_massa• 4 years ago

If the syntax requires special tooling to make it usable,

In Linux I'm using Geany https://www.geany.org/ with almost the default highlighting. The only change I made was to make the good and bad matches of parenthesis more visible. (In the default, the color of the parenthesis changes from black to blue or red, but it's too difficult to see. I changed it so the color is black but the background is blue or red. It's just a two lines change in the style, not special tool.)

In Windows I'm using WinEdt https://www.winedt.com/ and using again almost the default highlighting.

My recommendation is to mix () with [] and {} as recommended unofficially, instead of using only (). [For my personal code I use a few more [] and {} than the standard. I use [] for long [begin ...] blocks and {} for {define ...}. That helps a lot to find the problems.]

aidenn0• 4 years ago

If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

I think it is easier to put a nail through a 2x4 than a push-pin, but that presupposes I have a hammer; if I have a nailgun it's going to be easier to put 100 nails in than 100 push-pins. If I have neither, then the push-pin wins. There are always tradeoffs, but it doesn't mean that nails are inherently "hard" and push-pins are inherently "easy"

CraigJPerry• 4 years ago

I’ve been persuaded by HTDP that lisp, or at least “beginning student language” (BSL) is probably better than python for non programmers - if the goal is to understand programming.

I still like “think python” as an introductory text to programming https://greenteapress.com/thinkpython/html/index.html - and I’d still go python if the goal was a specific one-off outcome.

But now that I’ve gone through HTDP, that’ll be my textbook for beginners http://htdp.org/2022-2-9/Book/part_preface.html

Heavy book to drag to community evening classes though…

Siira• 4 years ago

Lisp syntax is simpler than other languages. Unfortunately, simplicity often clashes with conciseness. In Python, you can do neat stuff like `[a[a!=0][:, 8] for a in A]`. It is possible to somewhat replicate the same ease of use using (reader) macros, but Lisps seldom seem to have mature, standard macros for these kinds of stuff.

bmitc5• 4 years ago

No one can convince me that Python is an easy or simple language.

For parentheses, I find Racket and in particular Scheme to be enjoyable. My primary reasons are that it creates a massive amount of regularity and consistency in the language, of which there is none in Python. I had my girlfriend at the time take the How to Code: Simple Data course on edX, which uses the Racket learning languages. Not once did I need to answer a syntax question. Not one complaint about parentheses. She had no prior experience programming.

I find the people who whine and moan about parentheses are usually ones who have massive preconceived notions of what programming should look like or are so deep in some other language they are resistant to change.

I honestly feel like the best textual syntax is something like ML (as found in F#) or Scheme. Anything else is basically just random tweaks and way too much time has been wasted on textual syntax, which is conceptually bounded in terms of its expressiveness. But programmers and computer scientists are extremely myopic. Somehow we graduated from punch cards to text files and have plateaued ever since.

decent lisp-friendly tooling with a low barrier to entry, and DrRacket provides that

I'm not really sure what the commenter meant by that, but in my experience, all I ever needed was the auto-formatter and parentheses matching DrRacket provides. Matching delimiters occurs in any language, it's just that you have more of them.

outworlder2• 4 years ago

If the syntax requires special tooling to make it usable, isn't that a sign that the syntax is hard?

So, do you write your code on Notepad?

It's interesting that every time Lisp syntax comes up there's a comment like this. But when someone adds "refactoring" and "intellisense" to other languages it gets applauded. Why?

You dont need special tools. But being able to manipulate the sexpressions directly gives you more power.

strbean2• 4 years ago

If we were discussing teaching apprentice roof installers, you wouldn't argue that collated nails (the kind that feed into a nail gun) are worse for teaching because they are harder to use without additional tooling (a nail gun). The 'additional tooling' is in fact industry standard tooling that the apprentice will be using from the very start anyways, and that they need to be comfortable with as well.

derbOac• 4 years ago

For me, lisp was pretty intuitive when I first picked it up. It wasn't the first language I learned though.

When I was little my dad had a reverse polish notation calculator he explained and taught me to use. I think it was sort of a novelty for him, but when I encountered lisp in college my first thought was something like "oh this is just like reverse polish calculators".

There was sort of a strange learning curve for me though. The basics were fairly intuitive to me, then things got frustrating, and then easier again.

I really miss lisp though and wish it (or scheme or racket) had more widespread use, especially in numerical computing. I admit, though, that the hardware-lisp gap is bigger in my mind than the hardware-c gap, which extends to more procedural languages.

p_l2• 4 years ago

Having seen >1mil EUR of machinery stop because of a quick fix to python code done without special editor and thus resulting in having one #\Space less in one line, I would say Python is the language that requires special tools - not Lisp.

Worst case, you can align your parens vertically, like many AutoLISP programmers did when their only tool was Notepad or EDIT.COM. And usually incorrect parens result in code blowing up at build time, not runtime. Counting parentheses is definitely easier than counting whitespace.

If anything, Lisp just happens to be language with community that embraced quite advanced editor enhancements before many other languages got invented, and thus lisper's baseline expectations might be bigger than other developers'

spfzero• 4 years ago

You can reduce this, in a manner of thinking, to structure control being produced by: A) Visible characters B) invisible characters

kkfx2• 4 years ago

Hum... Python have a simple advantage: easy to learn, being mostly imperative, especially for those who have a background (even very little) in such languages (most students) and it's quick to fire up and also present almost everywhere with pip and venv to help.

Racket is a far more powerful tool, but also less immediate to learn, especially for those who have a background with imperative languages, not fast at all to fire up and not easy to use as a glue for anything else.

Python is a kind of bridge from unix shell scripts not so many nowadays have practice with and a script-versed programming language. Racket is about programming in classical terms, with an unique ecosystem.

In that sense probably Smalltalk with Pharo or classic (old) Lisp with Emacs are more acceptable Python since they do not act as a glue but they are FAR more immediate to use and have a purpose on it's own behind programming: they are end-users programming environments, as Python is an end-user scripting tool.

truncate• 4 years ago

My ex who wasn't from stem background was learning Python. Its very anecdotal, but few things I very well remember was:

(1) Here getting confused with scopes. E.g. assigning variable in one function and using it somewhere else, mixing global/local scope, assign/use order. Looking at that I was thinking a language that has more explicit and strict way to declare variables and look at scopes is probably better for beginners. The alternative with Python is that it can be somewhat confusing, and at times you see them only if they get executed. Racket definitely doesn't have that problem. It is as obvious as it can be.

(2) If your introduction is through some kind of project (data science, web app ...) you'll likely be using some object oriented features from very beginning. I saw her getting confused with `foo()` vs `foo.bar()` vs `foo.bar`. There was definitely a big gap in her understanding, but I think Racket's focus on functional paradigm and most libraries being that way -- is somewhat a nicer experience for beginners.

Overall, Racket is a simple language but can get fancy as far you'd want it to, so I think the barrier of entry is probably better than Python.

AtlasBarfed• 4 years ago

Muggles think in dynamic scope: they accumulate facts or locations and then refer back to them.

Local/lexical scoping is really a code structure/management/scaling thing. A name management system if you like.

As the joke goes, the two biggest problem in CS are naming and caching.

messe• 4 years ago

I always liked the variation that the two biggest problems in CS are naming, cache invalidation, and off by one errors.

brundolf3• 4 years ago

The problem is that Python doesn't make the explicit distinction between declaring a new (shadowed) variable, and assigning to an existing variable from an outer scope

wodenokoto• 4 years ago

I saw her getting confused with `foo()` vs `foo.bar()` vs `foo.bar`

I had the same problem when learning Python. Top that up with mutable and non-mutable structures and it can get very hard to make sense of Python as a beginner.

I remember I had a theory that foo.bar() would change foo and bar(foo) would return a value while leaving foo unchanged ... that turned out to be very wrong.

It also took me forever to realize that when you call foo.bar(), foo is the first argument of bar().

srcreigh• 4 years ago

Well, sometimes, other times foo is a module and foo.bar() calls a function bar with no arguments.

bmitc5• 4 years ago

I sometimes like to imagine a world in which .NET was cross-platform and open source from the start such that when F# was introduced it took over everywhere Python was popping up. It's a fantastic world to imagine but a depressing reoccurring dream.

2mol• 4 years ago

I love F#, but honestly Microsoft really hadn't built up the kind of trust back then (and maybe even now) to make this an even remotely realistic scenario.

lynndotpy• 4 years ago

Trust is one issue, another mah be perception. I know Microsoft has been embracing and extending open source recently, but I didn't know F# was open source. Even then, I still have the impression it's very much "Microsoft stack" and not worth investing energy in unless I'm doing "Microsoft stack" stuff.

einpoklum• 4 years ago

It's a fantastic world to imagine

How so? Link? Many people have never seen an F# program.

rbonvall• 4 years ago

Here you go: https://fsharpforfunandprofit.com/posts/designing-for-correc...

bmitc5• 4 years ago

What content are you looking for?

matheusmoreira2• 4 years ago

Depressing is something of an understatement. It's a fundamental unfairness of this world. We have all these nice technologies that never reach critical mass while far worse projects enjoy the support and investment of the whole world. Such is life for all Right Things.

seanhunter2• 4 years ago

Unfortunately for your timeline Python was already in wide use before F# was released (2005). You'd need .NET and F# to have been invented a little earlier for that to work out.

bmitc5• 4 years ago

Yes, but it was before the Python 3 debacle, and certainly early enough to be a contender. F# is a vastly superior language compared to Python and the core is much simpler. And look at Visual Studio Code for an example when Microsoft puts their might behind something. It only took 3-5 years for Visual Studio Code to dominate. But obviously this is all hypothetical, because it also needs Microsoft to treat F# as something other than a research tool to bring features into C#. I really don’t know why they didn’t view F# as a way to take market share from Python. It could have brought legions into their ecosystem. (Hypothetical given many’s weird obsession with hating anything Microsoft does.)

brundolf3• 4 years ago

I'm not even sure Python is an acceptable Python

musicale3• 4 years ago

I'm not either, but even with syntactic quirks like significant indentation Python seems to have provided a wider onramp than Lisp has.

bb882• 4 years ago

Pascal was the preferred language for original Mac OS development. Ada was used in DoD (and elsewhere) for more than a decade.

Both use a lot of "english" phrases which makes it easier for the novice to understand basic control structures.

musicale3• 4 years ago

Personally I hate it that Python has given up on backward compatibility.

I don't love Java/C++/JavaScript but I do like their backward compatibility (though JavaScript packages/libraries are often quicksand.)

musicale3• 4 years ago

I was being serious in case it's not obvious. I really do not like Python's disregard for backward compatibility.

matheusmoreira2• 4 years ago

It's the libraries that make Python acceptable. There's just too much technological wealth built on top of it.

maximilianburke• 4 years ago

Any time saved using Python libraries is lost when trying to manage Python environments and versions.

knoebber• 4 years ago

Grinnell alum here - our first CS class is in Scheme. I expected the class would be a breeze because I already had a few years of programming experience in Java/Python in highschool. Turns out that lisp is way different, and I was about as challenged as people with 0 programming experience. At first most of us were annoyed at having to learn an esoteric language without real 'industry' use, but by end of semester we all were super into it. It helped that our curriculum focused on fun problems like using recursion to draw things using a faculty/student developed scriptable gimp library.

bb882• 4 years ago

I remember a talk from a Michigan State professor at one Pycon a ways back that taught Python for their intro to CS. What I remember is that for the first time ever, he had people call him after the class and wanted to switch majors.

I think Scheme is awesome as long as it's not your first language, but I think if Scheme is your first introduction to CS particularly in college, it can be pretty brutal depending upon the instructor. I think a lot of higher learning institutions were trying to copy MIT's use of SICP for their intro courses.

kazinator14• 4 years ago

wanted to switch majors

To what, Art History? Poli Sci?

paroneayea• 4 years ago

Author of this blogpost here. I think the post is good, though it's mostly aimed at the perspective of "Racket is a very practical Lisp, for getting things done, akin to how Python is a very practical lisp" and also "DrRacket gives an accessible entry-point for Lisp for newcomers." Unfortunately I don't think Racket quite took this to be the rallying cry I hoped them to, to embrace Racket's lispiness as "The Python of Lisps" (which was the other alternate title I was debating between when I wrote it).

But in the comments here and as with most articles about Lisp, the conversation moves to... can newcomers understand Lisp's syntax? My spouse and I gave a talk about this very topic: "Lisp but Beautiful; Lisp for Everyone". https://fosdem.org/2022/schedule/event/lispforeveryone/

There's a lot in there (including demonstrations of representations of lisp which don't have parentheses at all). But the biggest point in the talk is that lisp isn't scary for new programmers... it's scary for experienced programmers. As we talk about in the video, my spouse and I co-ran introductions to programming using Racket aimed at humanities students with no required prior programming experience whatsoever.

What we found was that the students who had no prior programming experience, after just a few minutes, had no problem with the syntax (and DrRacket made it easy enough to pick up the language). But we did have complaints in the class about lisp's syntax... from those who already knew how to program. They already had a frame, and within that frame, lisp's syntax looked alien. Without a frame, students just accepted it and did fine with the syntax... great, even. (Many of them praised its clarity; like any decent lisp editor, DrRacket helps identify the kinds of parentheses-oriented errors that users think they're going to encounter.)

Anyway, I do more work in Guile these days than Racket, but both are really great systems with great communities. The thing I miss most about Racket though is that DrRacket gave an easy entry point for students which wasn't "and now start learning Emacs". (Guix is pretty great, however.)

mark_l_watson2• 4 years ago

I read your article when it was first published and agree with the sentiment.

Off topic (sorry) but one thing Racket is missing is great Python interop to mix in deep learning and other libraries. Common Lisp and Clojure have this support. Years ago I tried saving trained Keras weights and using them in Racket with the Matrix support: it works, but not very fun to use.

soegaard2• 4 years ago

Would something like `flomat` have helped?

https://docs.racket-lang.org/manual-flomat/index.html

jimbob45• 4 years ago

Lisp syntax is pretty rough if you want to prioritize maintainability. I can look at blurry C code and know generally what things are and what’s going on without a single character being legible. Lisps don’t typically have the same convenience. Given that code maintenance is usually about poring through thousands of lines of code quickly, I’d say this is a significant advantage for C.

However, Lisps have unparalleled macro flexibility. It’s a clear trade-off that Lispers often have trouble admitting is a trade-off.

xscott11• 4 years ago

I can look at blurry C code [...]

I'm kind of curious how much of this is the problem with parens, and how much of this is the conventions that Lisp programmers seem to mostly adopt. For instance, here's the concise 99-bottles from Rosetta Code for Racket:

    (define (sing bottles)
      (define (plural n) (~a n " bottle" (if (= n 1) "" "s")))
      (printf "~a of beer on the wall\n~a of beer\n~
               Take one down, pass it around\n~a of beer on the wall\n\n"
              (plural bottles) (plural bottles) (plural (sub1 bottles)))
      (unless (= 1 bottles) (sing (sub1 bottles))))
    (sing 99)

And even with a snippet this short, it's not quick for me to scan. Lispers generally like hanging parens, the indentation varies depending on what construct you're in, and that example uses recursion instead of a for-loop [0].

Ok, so let's turn the concise Python one into a hypothetical Lisp:

    (for i in (range 99 0 -1)
        (let b = "bottles of beer")
        (let w = "{b} on the wall")
        (print "{i} {w}, {i} {b}\n")
        (print "Take one down and pass it around, {(- i 1)} {w}.\n")
    )

I think you could "know generally what things are" with that version even if it was blurry. And of course, this "hypothetical lisp" is legal Racket/Scheme after implementing a few macros.

[0] I know Racket has for loops, but they didn't choose to use them in that example. Which is my point.

rendaw• 4 years ago

Couldn't this go the other way too? People who have no experience with programming languages have no basis for evaluating the comprehensibility of a language's syntax. I didn't have any complaints about BASIC until I tried Pascal, etc.

rg111• 4 years ago

I dreamed in parentheses. I'm not kidding, the only dreams I've ever had in code were in lisp

Every time I dreamed of code, I could never actually get what language I was writing in.

But, each time, the code text was wrapped thin and was long.

The theme was just perfect. I have looked at a lot of themes and color-schemes for vim (and terminal) and VS Code, but could not match the one from the dream.

It was just perfect.

And although I write a lot of Python, I think the code I dreamt of was typed.

throwamon• 4 years ago

See also: Pyret, a Python-inspired functional language by the creators of Racket - https://www.pyret.org/

zitterbewegung• 4 years ago

Racket is trying to make itself an acceptable Python at this time [1]. Also I used to use Racket and the biggest issue was the lack of batteries either were included or I could find a library that would work. But the biggest issue is the community itself [2] and that isn’t going to change any time soon.

1. https://github.com/racket/rhombus-prototype/blob/master/reso... 1. https://beautifulracket.com/appendix/why-i-no-longer-contrib...

rscho• 4 years ago

How is the Racket community an issue when the "issue" is that one guy bullies (some very particular) people? I've regularly posted reaaaally stupid things on the Racket forums and lists and people (including the core team) have always been super patient and welcoming. I really don't understand that "holier than thou" sentiment. I guess most people really shouldn't go eat in fancy restaurants or seek care from well-known hospitals either, then? Because many well-known chefs, lead doctors, etc. are really no nice people.

How is that the community's problem?

Semiapies• 4 years ago

Between s-expressions in Racket and indentation in Python, this thread really turns out all the people who whine about code that doesn't look like Java.

wraptile• 4 years ago

Weird that a hacker forum would be complaining about language fit for _hacking_ and instead yearn for corporate ideology. huh.

Racket Is an Acceptable Python (2019)

Related Stories