[HN Gopher] Racket Is an Acceptable Python (2019)
___________________________________________________________________
Racket Is an Acceptable Python (2019)
Author : behnamoh
Score : 131 points
Date : 2022-05-24 15:16 UTC (7 hours ago)
(HTM) web link (dustycloud.org)
(TXT) w3m dump (dustycloud.org)
| zitterbewegung wrote:
| 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...
| Labo333 wrote:
| See a previous thread:
| https://news.ycombinator.com/item?id=20392448
| dang wrote:
| Thanks! Macroexpanded:
|
| _Racket Is an Acceptable Python_ -
| https://news.ycombinator.com/item?id=20392448 - July 2019 (168
| comments)
| kkfx wrote:
| 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.
| zestyping wrote:
| 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.
| kbd wrote:
| 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.
| gus_massa wrote:
| > _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.]
| anon_123g987 wrote:
| 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.
| kazinator wrote:
| 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."
| derbOac wrote:
| 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.
| outworlder wrote:
| > 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.
| sigzero wrote:
| 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.
| petre wrote:
| No, the syntax is easy. Aligning the paranthesis is the
| annoying part where the tooling comes in.
| metroholografix wrote:
| 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.
| capn_duck wrote:
| 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.
| kazinator wrote:
| The syntax is easy in Lisp, but you don't know what it
| means without having the vocabulary of operators. The
| vocabulary is fluid and varies from dialect to dialect.
|
| However, the vocabulary part of a Lisp dialect consists of
| things which are named. Names can easily be looked up in
| documentation.
|
| Furthermore, you know what is and is not part of the form
| even if you don't recognize the operator: you know that
| (fnoozle blub (grogg)) q42 is invoking fnoozle with two
| argument expressions, and q42 has no part of it. You don't
| know how/if those two arguments are evaluated but if you
| look up fnoozle in the manual, it should be clear. The
| manual will talk about the arguments, and you can identify
| which of those is blub and which is (grogg).
| User23 wrote:
| The syntax is straightforward. You're referring to
| semantics. And in that respect, yes, Common Lisp is a very
| complicated language. The specification is about a thousand
| pages after all. I wouldn't say it's more complicated than
| C++ though, and personally I like simple syntax plus
| complicated semantics considerably more than complicated
| syntax and semantics. Personally I don't find separate
| function and value namespaces particularly confusing, but I
| do agree that it introduces some inelegance. Then again I'm
| demented enough that I think Perl is beautiful so YMMV.
|
| Even so there are some syntactic hints in terms of symbol
| naming, like how you can be pretty confident that a form
| that starts with WITH- is probably some kind of UNWIND-
| PROTECT macro that grabs a resource and cleans up after
| itself. Another example is that a symbol with asterisks for
| the first and last characters names a special variable.
| baq wrote:
| as the saying goes, the only intuitive user interface is the
| nipple.
| dagw wrote:
| And the only people who say that are people who never have
| struggled for hours trying to teach a baby to breastfeed
| kazinator wrote:
| That saying was probably invented by the same dolt who
| came up with "easy like taking candy from a baby",
| without having actually tried it.
| robertlagrant wrote:
| It's a union of them and people who know that their
| personal experience is not always representative of
| general experience.
| baq wrote:
| Wife managed to breastfeed four. Anegdata but it seemed
| rather intuitive.
|
| I'm aware not everyone is so lucky.
| [deleted]
| lastofus wrote:
| 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.
| soegaard wrote:
| > 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.
|
| That's the punishment for removing some of the "reduntant"
| parentheses from Scheme.
|
| Compare Clojure: (let [a 1
| b 2] (+ a b)) Scheme: (let
| ([a 1] [b 2]) (+
| 1 2))
|
| If for some reason, say, `b` get deleted a Scheme compiler
| can tell you which binding pair has a problem.
|
| In more complicated setups, in Scheme/Racket I indent the
| piece of code, and from the indentation I can see, where
| end parenthesis is missing.
| outworlder wrote:
| > 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.
|
| Mess up Python indentation and you get something like that,
| but worse.
| kazinator wrote:
| What editor were you using? Maybe it had broken
| indentation?
|
| You should be able to indent the code automatically and
| then the wrong subordination of the pieces shows up as
| wrong indentation.
|
| Like, e.g. what you think should be inside some conditional
| statement isn't intended at the expected level for that
| role.
| giraffe_lady wrote:
| 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.
| metroholografix wrote:
| If Hal Abelson and Jerry Sussman can use Lisp syntax to
| teach an iconoclastic, supremely philosophical class about
| programming that must rank amongst the best ever conceived
| and taught, 40 years ago, with blackboards and pieces of
| chalk, your average newcomer to Lisp should breeze through
| the process today.
|
| I've met a lot of folks that seem to possess mental models
| that are fundamentally mismatched with what Lisp expects:
| It's not just the syntax but a lot of the base models of
| the language that demand an open mind and time involvement
| before they get imprinted. And at least in some cases,
| blaming the parens becomes the easy way out of why one
| doesn't get it.
| jepler wrote:
| On a blackboard it didn't matter whether all the
| parentheses matched all the time
| wrycoder wrote:
| It's not the parentheses or the Polish notation that
| matter. Those are covered in the first chapter of any
| Lisp/Scheme book and they are trivial, especially with a
| proper editor that understands structure and will indent
| unambiguously accordingly. Unless you're stuck on simple
| editors like Notepad or Nano, there's no issue here.
|
| What's more challenging in Scheme, as Abelson and Sussman
| teach it, is the use of recursion instead of looping and
| in particular understanding that recursion is only
| equivalent to looping when the recursion is in "tail
| position", i.e. when there is nothing left for the
| calling function to do except return to its own caller.
|
| Common Lisp style tends to use looping, not recursion.
| metroholografix wrote:
| What matters on the blackboard (or a book) is
| "understanding" and that is not affected by a missing
| paren or two (which is a testament to Lisp's regularity
| of syntax).
|
| When they wanted their programs executed by a computer,
| their editor -Edwin- matched parens, exactly like how one
| would do it today, or even easier with things like
| Paredit.
| wrycoder wrote:
| And if you leave out a paren, the resulting auto-indented
| structure will look obviously wrong, signalling that you
| made an error.
|
| It's not so obvious in Python when you make an
| indentation error in a complicated if/elif/else
| structure.
| teddyh wrote:
| I've watched those videos. IIRC, the parentheses _always_
| matched.
| kazinator wrote:
| > _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.
| Siira wrote:
| 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.
| kkfx wrote:
| 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 wrote:
| > 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 wrote:
| I really like this analogy.
| aidenn0 wrote:
| > 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 wrote:
| 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...
| bmitc wrote:
| 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.
| JaumeGreen wrote:
| > 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.
| wrycoder wrote:
| 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 wrote:
| > 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 wrote:
| > _it should mark fields with obvious errors like unclosed
| quotes and parentheses_
|
| PyCharm does that and more.
|
| What editor are you currently using?
| wrycoder wrote:
| It still won't catch if/elif/else mismatches.
| bklaasen wrote:
| 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.
| paroneayea wrote:
| 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_watson wrote:
| 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.
| truncate wrote:
| 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.
| wodenokoto wrote:
| > 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 wrote:
| Well, sometimes, other times foo is a module and foo.bar()
| calls a function bar with no arguments.
| AtlasBarfed wrote:
| 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 wrote:
| I always liked the variation that the two biggest problems in
| CS are naming, cache invalidation, and off by one errors.
| brundolf wrote:
| 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
| throwamon wrote:
| See also: Pyret, a Python-inspired functional language by the
| creators of Racket - https://www.pyret.org/
| knoebber wrote:
| 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.
| dark-star wrote:
| 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.
| giraffe_lady wrote:
| 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.
| agumonkey wrote:
| 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.
| ModernMech wrote:
| > 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
| jimbokun wrote:
| As long as your abacus' LAPACK bindings are up to date,
| sure.
| agumonkey wrote:
| hey, all our abacuses need is a digital link and we're set
| rytill wrote:
| Can you share an example of such a talk?
| agumonkey wrote:
| iirc that's this talk
| https://www.youtube.com/watch?v=o9pEzgHorH0
| brundolf wrote:
| I'm not even sure Python is an acceptable Python
| musicale wrote:
| I'm not either, but even with syntactic quirks like significant
| indentation Python seems to have provided a wider onramp than
| Lisp has.
| matheusmoreira wrote:
| It's the libraries that make Python acceptable. There's just
| too much technological wealth built on top of it.
| musicale wrote:
| 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.)
| [deleted]
| rg111 wrote:
| > _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.
| phyrex wrote:
| (2019)
| bmitc wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bmitc wrote:
| F# has been open-source since the beginning or at least for
| a long time (before .NET Core).
| matheusmoreira wrote:
| 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.
| einpoklum wrote:
| > It's a fantastic world to imagine
|
| How so? Link? Many people have never seen an F# program.
| rbonvall wrote:
| Here you go:
| https://fsharpforfunandprofit.com/posts/designing-for-
| correc...
___________________________________________________________________
(page generated 2022-05-24 23:00 UTC)