[HN Gopher] Racket frustrates me
___________________________________________________________________
Racket frustrates me
Author : lycopodiopsida
Score : 83 points
Date : 2023-06-30 20:27 UTC (2 hours ago)
(HTM) web link (blog.winny.tech)
(TXT) w3m dump (blog.winny.tech)
| ashton314 wrote:
| > Coding is a tool to get stuff done.
|
| Sure, that's _one_ of its roles. Racket helps me think. Maybe I'm
| lucky, and work on genuinely novel problems where a malleable
| language beats libraries.
|
| So, sure, the Racket ecosystem leaves much to be desired, but
| _getting stuff done_ is only _one_ of programming's roles.
| zelphirkalt wrote:
| Some of the points are probably valid. But some I do not see as
| quite so valid:
|
| Many other deployments work similarly. Make a docker container
| and put it anywhere. Are Racket docker containers necessarily
| that much bigger than lets say Python ones or GNU Guile ones?
|
| Racket is packaged in GNU Guix btw., even, if I have had mixed
| experiences with the package, it should be mentioned. So someone
| already succeeded in packaging it in the package manager, that
| once was derived from Nix.
|
| > Do I want to write 4x the code (in Racket) because I forgot my
| secret move was actually all the pypi packages that I took for
| granted in Python?
|
| This really depends on what kind of code you are writing. When I
| wrote some Racket programs, I used mostly built-ins or perhaps 1
| or 2 dependencies. Depending on the project, maybe one needs more
| of those dependencies and writing them oneself would be too much
| work. But for simple dependencies that are easy to write oneself,
| I wouldn't want to use a dependency from PyPI.
|
| > Do I want to deal with being blocked due to not understanding
| how to use the less understood features of racket such as
| continuations, syntax-parse/syntax-case macros, units/signatures?
| You'll want to know about all these things to write effective
| Racket code.
|
| Hm, I don't know whether you want to. Do you want to be a capable
| programmer understanding more language concepts, being able to
| apply them perhaps in your next project or when learning your
| next language? Do you want to be able to express things elegantly
| than possible in Python for example? Do you want to know Scheme
| things? If not then OK, we all make our choices. I personally
| don't think it is good to avoid learning about something like
| continuations and stumble on without such knowledge as a
| programmer, but in more mainstream languages it probably is
| sufficient. However, one can also write lots of effective Racket
| code without going into macros. One does not have to follow the
| idea of having to make a language.
|
| > But then the real hard truths started to appear. I was losing a
| lot of productivity. The productivity losses were incremental but
| certainly slowed down my velocity significantly over the last
| seven years. Sure the language has a lot of wonderful features,
| but there's more to a good programming language than well, its
| programming language.
|
| This is probably the most important point raised.
|
| I hope though, that people who run into any shortages with Racket
| consider building the thing they are missing, if they are able
| to, to add to the ecosystem and to avoid the next person running
| into the same thing lacking. If no one ever writes their own, we
| will only ever stick with the status quo in terms of programming
| languages. (And fortunately people do write their own often.)
| winny314 wrote:
| > I hope though, that people who run into any shortages with
| Racket consider building the thing they are missing, if they
| are able to, to add to the ecosystem and to avoid the next
| person running into the same thing lacking. If no one ever
| writes their own, we will only ever stick with the status quo
| in terms of programming languages. (And fortunately people do
| write their own often.)
|
| Leadership needs to involve the community, then this can
| happen. Right now it seems that decisions around Racket are
| made at will - no process or formal discussion.
| patrec wrote:
| Life lesson: don't waste 7 years of your life and and personal
| growth on some weird fringe language, you will not get them back.
| It can pay off to make a serious commitment to a non-mainstream
| technology, but basically only if it allows you to do some _very
| concrete_ things that give you a big competitive advantage and
| that you could not reasonably achieve otherwise. Or if you are
| both unusually good at predicting the next hot thing, and the
| timescales are short enough. Racket is not a good bet in either
| regard (even if it 's a great language to learn certain
| concepts).
|
| All the lost productivity the poster is bemoaning could have gone
| into mastering hard and useful skills instead and these things
| compound.
| winny314 wrote:
| 100% this. It was a risk taken and it didn't pay off.
| latenightcoding wrote:
| Something that I find a little concerning about Racket is that
| AFAIK there are no alternative implementations. (Clojure and
| Common Lisp have a couple). Why is that? is it too complex?
| Jtsummers wrote:
| Racket itself came from PLT Scheme which was based on the
| Scheme standard (R5RS or R6RS at the time of Racket's
| diverging, can't recall which, wasn't paying much attention).
| It's still a fairly new language (13 years old now) and was
| largely Scheme compatible most of that time (still is,
| actually, if you stick to `#lang racket`, but not 100%). It
| also has no published standard, in this regard it's somewhat
| like Rust and others where to make an alternative
| implementation you've got to reverse engineer (fortunately it's
| open source) aspects of the current implementation.
|
| So it's not like you can just pick up R8RR (since it's on
| version 8, and keeping with the naming convention of Scheme
| standards as in R5RS) and start building something.
|
| Common Lisp also has a standard for implementers to follow, and
| is about 25 years older than Racket. That's given implementers
| a bit more time.
|
| Regarding Clojure, what's the status/quality of all the other
| implementations?
| kazinator wrote:
| Racket is a Scheme dialect (sort of), which has multiple
| implementations. People might be confused by the name Racket;
| it was clearer when it was called PLT Scheme.
|
| Common Lisp has more than a couple of implementations,
| especially when we take a historic view. However, say, Steel
| Bank Common Lisp has only one implementation.
| norir wrote:
| It is surprising to me that academics would not think that it is
| worth optimizing RSS for hello, world.
| kazinator wrote:
| There is no situation in which your language doesn't impact your
| productivity to some degree, sorry.
|
| When you've put 40,000 lines into the program, and your language
| is suddenly impacting your productivity more than you like, you
| can't just drop all that and switch!
|
| Your language has you hostage. "If you don't like the dent I'm
| putting in your productivity, go rewrite 40,000 lines in
| something else. Mouhaha!"
| yard2010 wrote:
| [dead]
| JimmyRuska wrote:
| Macros feel magical, this idea you can make your own language in
| no time so long as it's s-expression based, and make your own
| personalized vocabularies, expression flows, fit to purpose.
| Personal computing at its best!
|
| But from a working-with-other people perspective, imagine opening
| some code and finding random invented constructs you have to
| reverse engineer and step through. These days it seems everyone
| creates yaml or json files, and then implements some kind of
| declarative engine or interpreter to implement their DSL. This
| can be both easier to read and debug. For more complicated use
| cases you can tie it to a graph database that supports reasoning,
| instead of json/yaml
|
| Even so, is there really something that can be done with macros
| that can't be done, just as elegantly, with simple state
| machines, or object composition style in other languages?
| memling wrote:
| > But from a working-with-other people perspective, imagine
| opening some code and finding random invented constructs you
| have to reverse engineer and step through
|
| This feels just like working with another API to me. Macros can
| be arbitrarily complicated I suppose, but is the typical usage
| any more complex than learning an API? I don't really know, I
| guess, but my experience hasn't shown this to be that
| challenging.
|
| I can appreciate that programming languages are ultimately
| codifying a particular way to think about computation, and
| macros express more idiosyncratic ways of thinkingabout
| comouting that may not be readily understandable.
|
| I do think Racket has issues, but this isn't the first one I
| would cite.
| gus_massa wrote:
| [I'm biased, so I'd focus in some parts I disagree.]
|
| > _Do I want to iterate every 18 hours waiting for the
| pkgs.racket-lang.org build server to finish building my package?
| Then do it again because the build failed (my mistake, but now my
| users have to wait until later that week...)?_
|
| I agree it should be improved, but I think that deploying to the
| package system is something that happens not very often. The idea
| is to keep only a safe and stable version there.
|
| > _Do I want to write 4x the code (in Racket) because I forgot my
| secret move was actually all the pypi packages that I took for
| granted in Python?_
|
| It would be interesting if the author post in github a feature
| request for the 3 missing packages that are more painful. (3 is a
| good numbers to find someone else that care about one of them,
| more than 3 or 4 would be annoying)
|
| > _Do I want to wait 10+ minutes for my package to build in CI
| because some other package maintainer decided to pull in racket
| or racket-doc (which pulls in the entire big Racket
| distribution)?_
|
| Sometimes I use minimal-racket, and it's this is annoying. Most
| people just use the main distribution so this is not a problem.
| IIUC the author cares about a small footprint, so it's a special
| case. I use Ctr-C, but I guess there is a trick with raco pkg to
| do fix this automatically.
|
| > _Do I want to deal with being blocked due to not understanding
| how to use the less understood features of racket such as
| continuations, syntax-parse /syntax-case macros,
| units/signatures? You'll want to know about all these things to
| write effective Racket code._
|
| You can skip most of them to write effective Racket code.
|
| I use continuations only as an emergency exit inside nested fors,
| no fancy stuff. (I agree the fancy stuff is weird.)
|
| I think units/signatures is almost deprecated. It will be there
| forever to keep backward compatibility, but I expect new code to
| use modules instead of units.
|
| About macros:
|
| If you are programing alone just use syntax-rule. syntax-case is
| not so difficult unless you want to do weird stuff. I've done
| weird stuff in the past, but five years later I regretted it.
|
| If you are programing in a team, it's important that the macros
| have good error checking, because otherwise in case of an error
| it will expand crap that will expend to more crap and after a few
| rounds of crap expansion the poor soul that is using it will get
| a unintelligible error about code they didn't wrote. Here is
| where syntax-parse is useful, to ensure the initial code makes
| sense and expand only good code and give a good error reporting
| otherwise. syntax-parse is almost a separate DSL, so it's a lot
| to learn. (You can write the same stuff with syntax-case, but
| syntax-parse automates a lot of stuff.)
| MathMonkeyMan wrote:
| It's disappointing that this is the state of things from a
| "working programmer" perspective.
|
| Racket is, as far as I understand, a research and teaching
| language, as well as a viable scheme.
|
| I've used it for some [command line tools and side projects][1],
| but I never tried to deploy anything with it.
|
| Maybe a new [Chez][2]-based (as Racket now is) scheme is needed:
| one with much of Racket's nice syntax system, but focused on
| dependency management, targeted solely at "production" use, and
| other Serious Business Purposes.
|
| Not it!
|
| I'm not saying that Racket isn't a serious platform -- far from
| it. But the author's concerns, while expressed as a hot take,
| might be why Racket doesn't see wider industry adoption.
|
| Or maybe it's a chicken and egg problem.
|
| [1]:
| https://github.com/dgoffredo?tab=repositories&q=&type=&langu...
|
| [2]: https://www.scheme.com/
| kej wrote:
| > Or maybe it's a chicken and egg problem.
|
| Maybe Chicken Scheme is the solution, then?
|
| http://www.call-cc.org/
| znpy wrote:
| I don't see equivalent sobbing when somebody praise lets say
| Rust (random choice) for being productive, for the easiness of
| working with cargo or some other random stuff from the "working
| programmer perspective".
|
| Is this sad only when people have to talk about their pain
| points?
| armchairhacker wrote:
| Rust is a terrible first language for someone trying to learn
| programming
| winny314 wrote:
| Op here.
|
| It's important to recognize pain points so we do not become
| complacent with low quality developer experiences. Worse,
| complacency with software lifecycle at scale - will our
| product deploy on a cluster? Will our software be
| maintainable 5 years from now?
|
| Better we look at the pain points now than accept a poor DX
| for years to come.
| aidenn0 wrote:
| Totally ignoring your point and ranting about how much I hate
| Rust from easiness of working with.
|
| Not the language itself (which I love) I can write code so
| quickly in it, and I didn't struggle for very long with
| fighting the borrow checker, which seems to turn so many
| other people off.
|
| It's everything else. Long build times. "Modern" dependency
| management, which seems to mean package X only works with
| 0.6.x of package Z and package Y only works with 0.7.x of
| package Z and the current version of package Z is 0.8 and has
| a bugfix you really need. Though I should say that very few
| languages with a central repository don't have this problem;
| you make it easy to depend on libraries with unstable APIs
| and everyone will rush to do it.
| jandrese wrote:
| So many people rushed to copy the node/Python dependency
| management system that nobody asked if it was really a good
| idea.
|
| I totally agree that nailing everything down to the one
| particular minor rev causes way more problems than it
| solves. The worst part is I'm pretty sure you can be more
| general (give me version 3, or >3.3.1, not =3.3.1) but all
| of the automatic tools and online guides default to nailing
| it down to exactly one version because they're so damn
| paranoid about API changes.
|
| I will say that CPAN somehow avoided this problem. I think
| that is mostly because Perl programmers are far less
| liberal with dependencies, you don't typically see programs
| pulling in dozens or hundreds of modules the way you do in
| node projects. But it's remarkable how many old Perl
| programs can still pull the dependencies and start right
| up.
| pphysch wrote:
| > But it's remarkable how many old Perl programs can
| still pull the dependencies and start right up.
|
| I was surprised when I installed `git` and it pulled a
| couple dozen Perl packages from the distro repo.
|
| There's definitely something to be said about Linux
| distro maintainers/packagers being sort of middlemen that
| help enforce compatibility for popular Perl (or Python2,
| etc) packages.
|
| That is, there is a nonzero amount of greybeards between
| the developer and random end user, which cannot be said
| for your average npm or pip package.
| zitterbewegung wrote:
| I have daydreamed about making Racket more serious and calling
| it Tennis.
| akkartik wrote:
| I don't use Racket much, but Python certainly frustrates me. So
| what I want to know is where people land when all these languages
| frustrate them. Builds taking too long seems like a perennial
| problem, for example.
|
| (Currently I work in LOVE, but programs there use at least 100MB,
| so it probably won't be to OP's taste.)
| winny314 wrote:
| OP here.
|
| Python frustrates me too, but I just throw poetry and nix at
| it... keeps me not frustrated. :D
|
| It looks like my LOVE game uses about 99M resident... not too
| bad given it's pulling in a lot of libraries such as SDL2,
| luajit, audio decoders, etc etc.
|
| I think my concern is more with how do I embed Racket on low
| memory systems if a simple "racket script" is going to use a
| large % of the RAM to issue a `(sleep)`?
| tomcam wrote:
| For me it was Go. The toolchain just stays out of my way. I
| find Go much easier to deal with at a project level than
| anything else. YMMV because I'm a command-line kind of guy.
|
| Many of you will assume I'm a moron for choosing such a
| retrograde, simpleminded language. It's true! I am a moron
| compared to most HN readers. And your language is much more
| sophisticated than mine and had generics long before and didn't
| need a make keyword and stuff. No disagreement there.
|
| All I know is I can get the job done faster in Go than with
| Python, and I have type checking too. Plus a sane-ish package
| manager and a single, stable ecosystem. Plus I can deploy a
| single executable that even lets me embed assets inside it. It
| just stays the hell out of my way.
| zem wrote:
| anecdotally, towards the next generation of statically compiled
| languages, which have picked up a few affordances from the
| dynamic/scripting set. a lot of devops folk seem to be moving
| to go, for instance, and application developers have been
| showing some interest in rust, though personally I think it's a
| bit too low level to become universally popular. I wouldn't be
| surprised if something like crystal or native kotlin become
| popular down the road.
| aidenn0 wrote:
| I work in Common Lisp, which also is 100MB+ programs so likely
| won't satisfy OP either.
| schemescape wrote:
| Not if you use CLISP! It seems like bytecode vs. native
| compilation is a large contributor to memory usage (Racket
| uses Chez Scheme which compiles to native; same story for
| Node/Deno and V8).
|
| I have a low traffic web service and I wasn't happy with ~125
| MB of my 512 MB VM's memory being used up by SBCL, but I was
| able to just drop in CLISP and memory usage dropped to ~25 MB
| (and for reference: a "hello world" is under 10 MB with
| CLISP, similar to Python).
| proxyon wrote:
| Typescript. Kotlin. Java.
|
| I cannot imagine going back to Python, Ruby or PHP after using
| modern languages like these.
|
| Also, Java performance is good enough. Why did anyone ever
| abandon Java? It's easy to read, easy to write and pleasant
| enough to work with. If you need C level performance, by all
| means go with C, Go, Rust but Java to me is perfect, and
| Typescript is good enough for everything else.
| tmtvl wrote:
| People dislike Java because of all the...
| public void setPints (int pints) { this.pints =
| pints; } public int getPints () {
| return pints; }
|
| ...-esque stuff, and similar overly verbose constructs you
| get when you follow certain Best Practice guides.
|
| Personally I kinda like Java, despite it having 4 different
| kinds of brackets and object.method() syntax. Maybe it's the
| combination of 1 file 1 class and using classes for
| everything.
| paulddraper wrote:
| Use Kotlin.
| tmtvl wrote:
| ...because Kotlin doesn't use different kinds of brackets
| and object.method() syntax?
|
| Regardless, I'll stick to Common Lisp and C for the time
| being, they're nice.
| paulddraper wrote:
| No, it has that.
|
| It doesn't have the -esque syntax and similar overly
| verbose constructs.
| adamc wrote:
| In part, because the Java ecosystem kept getting more
| complicated. Fifteen or so years ago I was a full-time Java
| developer, but I wouldn't know half of what I need to know
| today, and I'm not very interested in going that route. Java
| kept the language simple-ish (not really, because they have
| added a lot on top of it), but the stack grew rapidly, and
| you have to know the tooling to function in that environment.
|
| Python remains a _lot_ simpler. It is getting more complex,
| but it has miles to go before it reaches Java-land.
| nightfly wrote:
| > Why did anyone ever abandon Java Boilerplate code.
|
| Java applications (mostly picking on tomcat here) being
| pretty much their own world of configuration, with lots of
| different places to look.
|
| Slow startup time pretty much kills it for lots of things I'd
| wanna write.
|
| It's memory management stuff sucks, from a sysadmins
| perspective. Any java application I deploy takes easily
| multiple times more memory than anything similar in a non-JVM
| language.
| wouldbecouldbe wrote:
| [flagged]
| zitterbewegung wrote:
| I tried using racket to do something useful and totally failed
| each time. Even if you are a single programmer making some kind
| of prototype I think we have gotten beyond the stage of picking a
| small language.
|
| Also, doing a rewrite into an Ml style language is really strange
| when they should probably be trying to become more competitive
| with other languages by building more batteries for it or fixing
| fundamental problems that were outlined here.
| priime0 wrote:
| > Also, doing a rewrite into an Ml style language is really
| strange when they should probably be trying to become more
| competitive with other languages by building more batteries for
| it or fixing fundamental problems that were outlined here.
|
| From what I know, Rhombus and Racket are parallel, mutually-
| beneficial projects. The development of Rhombus has contributed
| smaller features into Racket, while showcasing Racket's
| capability for language development. Rhombus is, in a sense,
| filling in gaps that Racket may be missing.
| serf wrote:
| >Even if you are a single programmer making some kind of
| prototype I think we have gotten beyond the stage of picking a
| small language.
|
| in what world does racket get classified as a 'small language'?
| it was one of the originals who focused on the 'batteries
| included' aspect for the sake of being more applicable in
| education.
| tryptophan wrote:
| Language ecosystem is more important than the language itself.
| Typing 5 lines of code because of fancy syntax is nice, but
| writing 20 doesn't take a significant amount of time. What does
| take tons of time however is figuring build systems, packaging,
| distribution, debugging, editor support, documentation,
| community, libraries, etc...
|
| I'm surprised no new languages focus on ecosystem. It is much
| less fun than making clever syntax I suppose.
| cogman10 wrote:
| > I'm surprised no new languages focus on ecosystem. It is much
| less fun than making clever syntax I suppose.
|
| Most new languages that I know of have a package
| manager/inbuilt dependency resolution mechanism and a fairly
| robust module system to try and support 3rd party dependencies.
|
| Rust, Go, Dart, D. You can expect every language post 2010ish
| to have this.
| __MatrixMan__ wrote:
| Would you say that that's a good thing? I'm so tired of
| trying to figure out which package manager is responsible for
| which thing and keep track of their various idiosyncrasies.
|
| I think nix might be the way--just have one package manager
| to rule them all--but I'm not aware of any language
| ecosystems that are leaning into this.
| cogman10 wrote:
| > Would you say that that's a good thing?
|
| Yup, the alternative is a C/C++/or Haskell scenario where
| instead of one generally accepted "right" package manger
| you end up with 20. You might get lucky like Java did with
| maven but that's no real guarantee.
|
| > but I'm not aware of any language ecosystems that are
| leaning into this.
|
| Bazel does. However, bazel (AFAIK) generally does things by
| leaning on the existing build systems of various languages.
|
| For software, unfortunately we are in a "jack of all trades
| master of none" scenario. I don't think there's a one size
| fits all solution.
| nequo wrote:
| > the alternative is a C/C++/or Haskell scenario where
| instead of one generally accepted "right" package manger
| you end up with 20.
|
| To be fair, Haskell doesn't have 20. It has two.
| cogman10 wrote:
| Just a sec, let me go create 18 more ;)
|
| But yeah, fair point. And maybe we can rely on newer
| languages to converge on a package manager faster than
| the languages of old did due to the internet.
| __MatrixMan__ wrote:
| Did Java get lucky? I thought it was out with maven and
| in with gradle--though it's been several years since I've
| been in that world.
|
| It's just kind of awkward how they all do the same thing
| in slightly different ways. But not meaningfully
| different.
|
| They all have some kind of lock file, and they all have
| some kind of cache that you have to handle specially if
| you don't want to download the universe in CI, and they
| all let you specify version restrictions but each uses
| different files to store these things, terminology to
| describe them, and uses a different configuration
| language for you to express them.
|
| Learning languanges would be so much fun if I didn't have
| to learn a new package manager each time.
| throwboatyface wrote:
| Pretty funny to say package management is table stakes and
| use go as an example. For a long time they had nothing, then
| hacky workarounds, and now they have a first party hacky
| workaround
| anacrolix wrote:
| I agree. I've been using Go as my primary language since
| 2011. Its package management has always been fairly simple,
| but deficient. Go modules have made things more accessible,
| but it lacks serious features and actually has quite a few
| bugs and edge cases. Every time I use cargo I'm blown away,
| it's incredible. People often gloss over Go and lump it in
| with Rust which is giving it far too much credit.
| cogman10 wrote:
| I'm not saying it's great, but saying it was thought
| about even though one of go's design philosophies was to
| be as minimal as possible. That is, it's something that
| was thought of as part of the language development.
|
| The same can't be said of slightly older languages like
| C#, Java, or python. Perl, for all its foibles, was
| probably the first language with a more modern package
| management system (CPAN).
| lyu07282 wrote:
| I think its more like _pretending_ that things are simple
| (or that a simple solution is enough), when in truth some
| things just aren 't simple and pretending otherwise is
| unwise. Like how they ended up adding a package manager
| later on, which of course was never part of the initial
| design because they thought nobody needs to version their
| dependencies. Or how they ended up adding generics later
| on, because they thought nobody will ever need to do
| "abstract things".
|
| The problem is if you don't consider these things in your
| initial design, the solution you end up with later tend
| to be worse.
| jonhohle wrote:
| Is it even fair to call them packages? It's a slightly more
| convenient method of repo sub modules, but there isn't any
| object reuse or sharing outside of a workspace.
| tptacek wrote:
| Getting packages working in Go is approximately as low-
| friction as it is with any other language: "go get
| <whatever>". Packages are qualified by their Git repository
| URL, which addresses an important supply chain security
| issue (but creates other issues). Go has supported a
| thriving ecosystem of third party packages since
| approximately the moment it went mainstream.
|
| So, ultimately, all people are saying when they knock Go's
| package management is that they don't like how it works.
| That's fine, I don't like how all sorts of things work. But
| "nothing" is false, and "hacky" is so subjective as to be
| practically worthless. Obviously, the reason Go gets picked
| out in these discussions is that it's quite successful as a
| language, and, to me at least, it follows obviously that
| they solved package management to some level of the
| community's satisfaction, because languages without package
| management aren't successful.
|
| If we wanted to hash out the pros and cons of different
| package management strategies, that's all the thread will
| be: just hundreds of back-and-forth messages about package
| management. It's a big topic.
| 0cf8612b2e1e wrote:
| >... Obviously, the reason Go gets picked out in these
| discussions is that it's quite successful as a
| language...
|
| When I wrote Go, the official language policy is that you
| do not need versioning and should not make breaking
| changes. Throw everything into a vendor/ if you must. For
| me, that kind of stance on package management definitely
| warrants attention.
| tptacek wrote:
| People have all sorts of thresholds past which attributes
| of package management warrant attention. Some of them are
| even reasonable. But it's not legitimate to claim that a
| language doesn't have any effective package management,
| at least when that language is (a) popular and (b)
| idiomatically dependent on 3rd party packages, simply
| because those thresholds get crossed. Go self-evidently
| has effective package management, and has for over a
| decade.
|
| There are _lots_ of things I don 't like about NPM. But
| imagine claiming that Node doesn't have real package
| management. You can't even write a for-loop in Node
| without a package. Go isn't quite that far gone, but it's
| pretty hard to write idiomatic Go of any significance
| with zero packages.
| sanderjd wrote:
| I think you're right that Go's current approach is
| similarly fine as the other ecosystems with basically
| fine approaches.
|
| But they really did launch with no solution and take a
| fairly long time to figure it out.
| jonahx wrote:
| > What does take tons of time however is figuring build
| systems, packaging, distribution, debugging, editor support,
| documentation, community, libraries, etc...
|
| Yes.
|
| https://www.hillelwayne.com/post/learning-a-language/
| winny314 wrote:
| Op here.
|
| I disagree. You can get up and started in most language
| stacks fairly quickly. Keep focus, learn to sort advice into
| helpful and unhelpful buckets, and start building with a goal
| in mind.
|
| For example - I hadn't touched fennel nor Love2d until about
| a month ago, and we made something happen.
|
| You can do this too.
| jpe90 wrote:
| I recently learned Fennel and cranked out a Love2D game as
| well. Not only that, but I discovered it's trivial to run
| the game on some spare nintendo consoles I have lying
| around, because Lua is insanely portable.
|
| In contrast, I spent a ton of time trying to build other
| lisps that are designed to be embeddable on those consoles
| and got nowhere.
|
| Fennel rocks. Such a pragmatic and well designed mini-
| language.
| badsectoracula wrote:
| > I'm surprised no new languages focus on ecosystem. It is much
| less fun than making clever syntax I suppose.
|
| In a way it is. After all if i make a new language, i can
| control what it can do and how it evolves but i can't control
| other people to force them use it.
| paulddraper wrote:
| > I'm surprised no new languages focus on ecosystem.
|
| All of them?
|
| Go, Rust, Kotlin, TypeScript
| tikhonj wrote:
| Typing 20 lines doesn't take much more time than typing 5
| lines, but dealing with 5x more code thanks to an inexpressive
| language sure is an ongoing drag on productivity that just gets
| worse over time--while _figuring out_ tooling /packaging/etc
| is, mostly, an up-front cost. Obviously better tooling is
| better, but my experience has been that [?]everyone overvalues
| up-front costs vs ongoing costs because they're more legible.
|
| Frankly, I wish new languages focused _more_ on flexibility and
| expressiveness even if that made things harder up-front!
| remexre wrote:
| > I'm surprised no new languages focus on ecosystem. It is much
| less fun than making clever syntax I suppose.
|
| Honestly, this is a lot of the draw of Go and Rust for a lot of
| people; other than debugging (which I can't speak to from
| experience, but as I understand it, both are on par with C++),
| the points you hit on above are all things Go and Rust have
| really solid answers to compared to their contemporaries.
| whalesalad wrote:
| higher resident memory is not ideal, but is it a dealbreaker?
|
| Anyhoot - I think clojure is the best lisp there is right now,
| but for better or worse it is tied to the jvm and seems to be
| stagnating.
| Jach wrote:
| Do you use Clojure? I'd give the title of best Lisp to Common
| Lisp, the Actually Lisp -- it's so Lisp it even has Lisp in its
| name and runs decades of Lisp code, something neither Clojure
| nor Racket can do any more easily than Python. I suspect many
| of the author's frustrations would go away if he just used
| CL... though he'd find new ones for sure.
| aidenn0 wrote:
| Hi RSS being a dealbreaker for OP rules out most lisps. ECL
| might be low enough, but certainly SBCL and CCL will be too
| high.
| schemescape wrote:
| Try CLISP. It uses a VM, so it's much simpler and uses less
| memory (but is slower, obviously).
| norir wrote:
| High RSS makes me wonder how well the language is designed and
| implemented. Luajit gives you many of the things racket does
| (and can be easily extended to add any racket feature) without
| having crazy high RSS. Even though it may seem minor, it gives
| me a lot more confidence that at a minimum, luajit isn't
| _badly_ designed.
| placesalt wrote:
| There's a live coding talk by John Carmack where he uses Racket
| for making small programs for the Oculus:
|
| https://www.youtube.com/watch?v=ydyztGZnbNs
|
| He seemed happy enough with the language.
| kaushalvivek wrote:
| I had a professor at college who mandated Racket as the mode of
| learning for a software engineering course. I remember how Racket
| just ended up taking centre stage, figuring language-specific
| concepts and hacks out let the larger engineering concepts fade
| into the background.
|
| I did not learn much in that course.
| chongli wrote:
| They used it improperly then. Racket is used for the first year
| intro CS courses at my school. They do not use the full
| language! They use the beginning student [1] and intermediate
| student [2] versions of the language.
|
| These are highly restricted teaching versions of Racket which
| do not include the vast majority of the language features. They
| also use beginner friendly names such as _first_ and _rest_
| instead of the cryptic _car_ and _cdr_. These languages allow
| students to learn functional programming and basic concepts
| such as recursion, linked lists, association lists, higher
| order functions, trees, and graphs without worrying about
| programming language details such as side effects, fixed size
| numeric types, memory allocation, pointers, macros, compilers,
| etc.
|
| For that purpose, Racket seems pretty hard to beat! For the
| professors, it also has the (nice) side effect that many
| students with previous programming experience are less likely
| to have learned Racket (or any functional language for that
| matter). This has been argued to put the students with and
| without programming experience on a more equal footing.
|
| [1] https://docs.racket-lang.org/htdp-langs/beginner.html
|
| [2] https://docs.racket-lang.org/htdp-langs/intermediate.html
| justinpombrio wrote:
| * * *
| goda90 wrote:
| My professor for "Programming Language Concepts" was a
| contributor to Racket and it was center stage of the class. He
| did his lectures in DrRacket. He did a great job building up
| from principles to explain things, but was also very
| opinionated and had very high standards for homework. It was a
| tough class for me.
| paulddraper wrote:
| Did we go to the same college? :)
|
| In seriousness, Racket is semi-commonly used in educational
| settings. Especially for "functional programming"-type courses.
| dangrover wrote:
| Northeastern, Rice?
| stephenhuey wrote:
| He went to IIIT Hyderabad if I found the right Samsung-
| associated guy of the same name on LinkedIn. I went to Rice
| when Racket was Scheme and definitely it got pushed hard on
| me, at least in the intro CS course. :) But that was back
| when CS was one of the smallest majors, and now it's the
| largest at Rice and their curriculum is quite different!
| BeetleB wrote:
| My introductory course was in C/C++. I already had programming
| experience, but for those that didn't - your statement would
| apply well to it as well.
|
| So many concepts got in the way of actually learning
| programming: You have to include header files for basic I/O to
| work. You need to understand functions to get _any_ program to
| work. Pointer syntax sucks. Strings are complicated.
|
| Coming from BASIC and QB, the barrier to entry in C/C++ was way
| too high. To be frank, Racket is more suitable, even if it's
| not the best option.
| armchairhacker wrote:
| Can you give specific examples?
|
| I'm not doubting you. I'm interested in what parts of Racket
| could be confusing to beginners, maybe to make better courses
| [deleted]
| soulbadguy wrote:
| Some good points, but i find the tone a bit off.
|
| I have been eyeing racket for a while now, but could never quite
| make the jump. Racket (the programming language) has definitely a
| lot of potential, but i do believe the academic side of it and
| the focus on the "build your own language" part might be an
| impediment to racket growth.
|
| If i was to suggest some stuff :
|
| - Clearly split Racket (and typed Racket) the language, evolution
| of scheme and Racket the PLT framework use to build and construct
| new languages. Racket / typed Racket should focus on more
| production/libraries for regular programmer - More
| examples/libraries/package not directly related to PL and PL
| teaching. Create a website solely for Racket/typed racket, with
| the academic part. - DrRacket always felt and looked alien to me.
| I can't really judge the feature set, but having vscode as the
| defacto IDE i think would be it more welcoming - This one is will
| definitively be controversial but introduce a "curly brace"/C
| style syntax for Racket. Something implemented at the reader
| level. Same semantic/runtime behavior, and a reader/printer to go
| between Racket and {C|rust}SyntaxedRacket.
|
| That's a lot of effort, so why do this ? I believe the world is
| looking for a better python. There is a lot of contender right
| now (julia, nim , etc... etc...). I think racket should also
| throw their hat in the ring.
| priime0 wrote:
| > Clearly split Racket (and typed Racket) the language,
| evolution of scheme and Racket the PLT framework use to build
| and construct new languages.
|
| It's very much possible to use Racket without interacting with
| macros and language-building features.
|
| > Racket / typed Racket should focus on more
| production/libraries for regular programmer
|
| Libraries are dependent on the community, which unfortunately
| is comprised of mostly academic folk at the moment.
|
| > DrRacket always felt and looked alien to me. I can't really
| judge the feature set, but having vscode as the defacto IDE i
| think would be it more welcoming
|
| I do agree -- if I remember correctly, DrRacket was primarily
| built as a pedagogic IDE, not one meant for more professional
| use. VSCode, however, does have the "Magic Racket" extension.
|
| > This one is will definitively be controversial but introduce
| a "curly brace"/C style syntax for Racket.
|
| Not necessarily C-style syntax, but you could take a look at
| Rhombus. It's meant to have a more approachable syntax compared
| to S-expressions.
| chriswarbo wrote:
| > his one is will definitively be controversial but introduce a
| "curly brace"/C style syntax for Racket. Something implemented
| at the reader level. Same semantic/runtime behavior, and a
| reader/printer to go between Racket and {C|rust}SyntaxedRacket.
|
| This already exists, in a few forms (e.g. Sweet Expressions). I
| wrote a blog post listing a few, for whenever this topic comes
| up ;)
| http://www.chriswarbo.net/blog/2017-08-29-s_expressions.html
___________________________________________________________________
(page generated 2023-06-30 23:02 UTC)