[HN Gopher] Racket: Lisp for the modern day
___________________________________________________________________
Racket: Lisp for the modern day
Author : Decabytes
Score : 241 points
Date : 2023-06-29 12:10 UTC (10 hours ago)
(HTM) web link (www.deusinmachina.net)
(TXT) w3m dump (www.deusinmachina.net)
| markstos wrote:
| Looks great, but didn't answer the question for me of why to
| learn this over TypeScript or Rust.
|
| The answer seems to be in the title: this of particular interest
| for those already interested in Lisp or Scheme.
| aobdev wrote:
| I would argue that learning Racket as part of a foundation in
| CS would make it easier to learn TypeScript and Rust.
| zelphirkalt wrote:
| Sibling comment already asked the important question to ask
| yourself, but my answer would be: Language design decisions and
| the typical benefits of using Scheme dialects or former Scheme
| dialects, as Racket does not consider itself a Scheme any
| longer, iirc.
|
| For example being able to make good use of recursion, being
| able to write programs more elegantly.
|
| Racket, in contrast to JS or TS, comes with lots of batteries
| included, therefore not requiring so many third party
| dependencies. Time and time again I see the Racket docs and
| think: "Ah Racket has got something for that/got you covered."
| Also it is rich in programming language concepts. You can write
| your programm in any of the languages that come with Racket, or
| you can write it with function contracts or you can use Typed
| Racket.
|
| At its core, it is a much cleaner and better designed language
| than TS will ever be due to TS' JS legacy.
| mcpackieh wrote:
| > _Racket does not consider itself a Scheme any longer,
| iirc._
|
| Racket (the language) itself is no longer a Scheme, strictly
| speaking, but still feels generally "schemey" in the broad
| scheme of lisps. However, Racket (the software package) does
| ship with a Scheme or two, namely R5RS and R6RS.
| markstos wrote:
| I coded in Perl back when it dominated web development and
| came to value practical over beautiful in language choices.
|
| CPAN made Perl the best choice for many tasks and the same
| can be said of NPM for choosing TypeScript now, regardless of
| the elegance of the language.
|
| But I'm also a fan of "language tourism". Even if one
| language is more practical, visiting other language cultures
| can make us better developers overall.
|
| I studied Haskell for a bit which gave new ideas for how I
| use Perl. Culturally, Haskell was using a lot of functional
| programming concepts and recursion. Those were possible in
| Perl but not popular.
|
| I'm sure there is value in studying Lisp languages for those
| who end working mostly in TypeScript or Rust
| disconcision wrote:
| Even the racket teachpack libraries designed for education
| are very capable; I was able to make this structured editor
| with only using teachpack content without external deps:
| https://github.com/disconcision/fructure
| soulbadguy wrote:
| What are you looking for in learning a new language ?
| markstos wrote:
| TypeScript as a job skill for web work.
|
| Rust because it's the other language I see most often see
| coders learn to build their own apps. It has a good
| reputation for developer experience, security and speed.
|
| I've heard enthusiasm for lisp-based languages for a couple
| decades and don't doubt the merits of Racket.
| soulbadguy wrote:
| Yeah in which case I think you are fine skipping racket or
| lisp for that matter
| nsm wrote:
| IMO a couple of cool aspects of Racket that aren't called out in
| beginner guides, but I think are really useful in real programs:
|
| 1. The use of custodians on a per-(green-)thread basis that
| brings "oh yes, if the thread crashes or is shutdown, racket
| guarantees that all open files/sockets/resources will be shut
| down". For example you can use this to ensure that a timed out
| client doesn't cause unnecessary resource usage.
| https://docs.racket-lang.org/more/index.html#%28part._.Termi...
|
| 2. Events and composable concurrency from Concurrent ML - Unlike
| Go's channels, concurrent ML events are composable up the stack,
| and have some nice things built in like "NACK events" (allowing
| cancellation down the stack). Unfortunately there aren't great
| primers about using this that I know of apart from the Kill Safe
| Synchronization Abstractions paper.
| https://users.cs.utah.edu/plt/kill-safe/
|
| 3. Sandboxing - https://docs.racket-
| lang.org/reference/Sandboxed_Evaluation....
|
| Some of these were added to make it easier for the IDE to manage
| errant programs that could be written by beginners, but it is
| also a very "applicable to production" set of tools. Racket
| internalizes Extra-linguistic mechanisms
| https://felleisen.org/matthias/manifesto/sec_intern.html
|
| Also the fact that various DSLs can inter-op with each other
| directly, so that you can use something like a binary parser
| description, as if it was just another Racket library. For
| example this description of the format
| https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-...,
| is directly included in another file as a regular library
| https://github.com/Bogdanp/racket-binfmt/blob/master/binfmt-...
|
| I agree that startup time is not a winning aspect of Racket. My
| naive understanding is because Racket is not a direct bytecode
| interpreter like CPython, but actually has to run a compile step
| to native code, and doing that for programs + their required
| libraries necessarily takes at least a couple of hundred
| milliseconds even before anything can start running, while
| CPython can pretty much start executing from the get go.
| jes wrote:
| I'd like to play around a bit with Racket. I have been using
| Slime with Common Lisp for years. From what I'm reading, it
| sounds like Geiser[1] might be a Slime-alike package for Emacs.
|
| Thoughts or advice?
|
| [1] https://www.nongnu.org/geiser/
| _emacsomancer_ wrote:
| There's Racket Mode[1] for Emacs, which is very nice.
|
| [1]: https://www.racket-mode.com/
| jes wrote:
| Thanks for the heads up! Looks great, will take it for a
| spin.
| bmitc wrote:
| I really wanted to dive into Racket a few years ago and still
| really like Racket. But this is when they switched focus to the
| Rhombus project, which killed a lot of interest and personal
| momentum I had going for Racket. It has also become clear that
| Racket's maintenance core is too academic. I don't think Racket
| is too academic, but by the very nature of Racket's primary
| community being professors and graduate students, it means there
| is a very small core team with a lot of the interest and use
| outside of that core being shortlived as students go through PhD
| programs. There are a few nonacademic core members, but there are
| few.
| fn-mote wrote:
| IMO this part is FUD:
|
| > when they switched focus to the Rhombus project, which killed
| a lot of interest and personal momentum I had going for Racket
|
| The language has been "complete" for a long time. If you're
| actively trying to get something done, I think it's unlikely
| that some core language work is going to stop you.
|
| It isn't clear what domain the parent wanted to work in; I
| won't say it's impossible they had problems but ... details are
| everything at this point.
|
| The academic part of Racket gave rise to `syntax-parse`, a
| truely fabulous improvement over the standard
| Lisp/Scheme/whatever you used to work with way to write macros.
| bmitc wrote:
| Why is it FUD? It's my own feeling. In this specific case I
| had just spent a week of my and my work's time and money
| learning Racket at an official Racket school only to find out
| at the end that they're creating a new "surface" syntax. The
| split of do I learn and participate with Rhombus or Racket is
| a concern. The idea that the core maintainers, or really the
| core maintainer (singular), is busy with Rhombus is a
| concern. The explanations given at the time for the Rhombus
| project were primarily dubious and unclear. The uncertainty
| and doubt were not created by me. It was enough to make me
| move on. Other languages like F# and Elixir suit my needs.
|
| > The academic part of Racket gave rise to `syntax-parse`, a
| truly fabulous improvement over the standard
| Lisp/Scheme/whatever you used to work with way to write
| macros.
|
| That's not the academic part I am referring to. My comment is
| about who the maintainers and users are and how their
| profession or studies affect how Racket is interacted with.
| (This is not a complaint or judgement. It's an observation.)
|
| > The language has been "complete" for a long time.
|
| There are a fair number of bugs in Racket's libraries,
| including core ones. They aren't discovered because academic
| users are not touching bits that more industrial-oriented
| users would find. In particular, I am thinking of the GUI
| toolkit, and in my experience, only one person is capable of
| fixing those.
| singularity2001 wrote:
| They call #hash[(a . b)] modern? Maps should be a first class
| citizen with first class syntax and not ... that.
| zsh_89 wrote:
| As a pretty experienced programmer, who make a living by writing
| code for almost 10 year(with a CS master degree), I would like to
| say something to new learners of CS who need making money by CS
| skill in the future:
|
| + almost everything related with LISP is fun
|
| + but they have VERY limited use in industry, for very good
| reason;
|
| + you should try spend at least same amount time (as on LISP
| topic) to learn something like leetcode(or even higher level of
| competitive programming, which improve your skill of converting
| your idea to code fast and basic math thinking; useful in
| interview), job-oriented CS book. You'll be a better problem-
| solver and more ready in job market.
|
| + If you're very sure you will be financially OK, just learn
| anything you like and ignore this message.
| waffletower wrote:
| I think there are many people reading this thread who develop
| using a variety of Lisp as their primary language and are more
| than adequately compensated financially, and yes, in 2023.
| zsh_89 wrote:
| [dead]
| vindarel wrote:
| Common Lisp has many industrial uses though.
|
| (https://github.com/azzamsa/awesome-lisp-companies/
|
| https://lisp-lang.org/success/
|
| http://www.lispworks.com/success-stories/index.html
|
| such as
|
| https://www.cs.utexas.edu/users/moore/acl2/ (theorem prover
| used by big corp(c))
|
| https://allegrograph.com/press_room/barefoot-networks-uses-f...
| (Intel programmable chip)
|
| quantum compilers https://news.ycombinator.com/item?id=32741928
|
| etc, etc, etc)
| dunefox wrote:
| > + but they have VERY limited use in industry, for very good
| reason;
|
| And what would these very good reasons be? inb4 "only for
| single programmers", brackets are difficult for normal
| programmers, macros can't be understood by mortals, and other
| non-issues that have been discussed to death.
| glonq wrote:
| I will argue against your first point ;) ...but otherwise
| pretty much agree.
|
| I learned LISP in college, way back when expert systems were
| the future of AI.
|
| The worst thing that I could probaby do professionally is to
| write something in LISP that needs to be adopted and maintained
| by somebody else in the future.
| dizhn wrote:
| I am getting a weird rectangular box on this website that is not
| allowing me to read the article in peace. My assumption was they
| did want me to read it, but it doesn't seem to be the case. It
| says "Discover more from Deus In Machina" on this box. I would
| maybe want to discover more except for 2 things, #1 it won't let
| me read the current thing, #2 i don't know that other things will
| let me read it either.
|
| I think they should fix this quite obvious bug before writing
| more articles.
| mrkeen wrote:
| I get this kind of thing on plenty of articles linked from HN.
| Sometimes it's a paywall. Othertimes it's just an inexplicable
| UX race to the bottom. The first stages of "enshittification" I
| guess?
| dfan wrote:
| This is an annoying Substack thing. Click on "Continue reading"
| (if you wish to).
| doodpants wrote:
| I use the "Disable JavaScript" extension in Firefox, and
| created a rule which disables JavaScript for the entire
| substack.com domain so as to avoid this nonsense.
| Unfortunately, some sites such as this one use their own
| domain name despite being based on Substack, so I still have
| to disable it manually in these cases.
| [deleted]
| efficax wrote:
| just click continue reading...
| ArchieMaclean wrote:
| Beneath the large obvious green 'Subscribe' button there is
| some low-contrast grey text ('Continue reading') that, when
| clicked, hides the box. This is on Substack's side, not the
| author of the article.
| uneekname wrote:
| I love Racket, re-wrote my website in it and a few other
| projects. I'd call myself an advanced beginner, I guess.
|
| > Racket excels as a programming language for young learners and
| beginners.
|
| I honestly think Racket could do more to be beginner-friendly.
| The documentation is excellent, but difficult to understand as a
| newcomer. There are some great little tutorials that are easy to
| work through, but the ramp from there to writing your own Racket
| programs is steep imo.
|
| I don't know of any other language with so many batteries
| included. Racket deserves to see community growth, and hopefully
| with that will come more resources for folks to get started
| no_wizard wrote:
| My limited use of Racket is purely due to how it has its own
| IDE and nothing else.
|
| Its fine, and its pretty good for Racket code (and its
| variants, like typed racket) but when I'm working on a real
| project I have other things I need to write too, like CSS,
| HTML, TypeScript, bash scripts etc.
|
| Its more ecosystem to be more adoptable IMO.
|
| I love it for learning though, but turning racket into a
| production level language w/ proper ecosystem has a way to go
| jimhefferon wrote:
| Lots of folks use it outside of Dr. Racket.
| patrec wrote:
| > Racket is probably the finest example of a modern day lisp bar
| none
|
| It's not. There are several nice and unique things about Racket,
| but it's a pretty poor example of a lisp, to the extent that if
| you want to understand what's good about lisp you'd probably be
| better off learning emacs lisp than racket.
| clircle wrote:
| go on...
| iNerdier wrote:
| I'm slightly confused by the aim of this article. It goes out if
| it's way to state in the first few paragraphs how approachable it
| is to newcomers, then dives into talking about how good it is at
| making, other programming languages.
|
| How big a desire of the average neophyte is to make themselves
| another language?
| poslathian wrote:
| Is this any different than a beginner musician who learns to
| play their favorite songs but also write their own?
| agumonkey wrote:
| I don't think both aspects are to be analyzed at once. Or
| unless maybe through the lens of minimization.
|
| In most mainstream languages you have a large syntax, lots of
| idiosyncracies, and limited ability to hack with the innards of
| your tool. Scheme is small, regular and freeing.
|
| Now personally, after my first year of college, I asked why on
| earth can't we access the methods in an object (java4 at the
| time) to generate a UI to dispatch / interact with it. Teacher
| rapidly walked me off the room while mumbling "but that would
| be metaprogramming!". I left confused about his annoyed tone.
|
| Not until year 4 we had the chance to see
| reflection/intercession, lisps, macros.. I wish someone showed
| that to me when I was 12.
|
| ps: it might not be obvious, and maybe I'm wrong but I see
| adhoc DSL's everywhere I work. ORM, build tools, they're all
| pseudolanguages.. and people keep reinventing them. Scheme/lisp
| offers it on a silver plater for you.
| [deleted]
| ssivark wrote:
| It's taking about "little languages" (DSLs), somewhat in the
| spirit of what one thinks of as libraries/APIs (on a continuum,
| all the way to something with its own syntax... Like regular
| expressions).
|
| https://chreke.com/little-languages.html
| err4nt wrote:
| There are a lot of problems where people struggle to simply put
| the problem into meaningful terms, so they can think about it.
|
| If you deal with the same problem space a lot, having a Domain-
| Specific Language (DSL) can let you execute that vocabulary and
| work at the level of the terms that fit the problem space best.
|
| This is a lot smaller in scope than designing a whole
| programming language, think of it like a unique vocabulary for
| solving specific problems and automating specific kinds of work
| you do!
| mst wrote:
| A neophyte wants to make a thing that -does- something, but
| part of the idea of Racket's Language Oriented Programming
| thing is to increase the subset of somethings for which
| throwing together a quick DSL makes for easier/nicer code.
|
| I've not watched a relative neophyte try and actually -do- that
| so I can't comment on how far they've got with it, but making
| "creating DSLs" approachable seems like a really interesting
| thing to be aiming for.
| andsoitis wrote:
| There's an elegance to a language that works great for
| beginners but also scales to very sophisticated use cases.
| p4bl0 wrote:
| Indeed, Racket is a platform for active academic research in
| both computer science education and programming language
| theory.
| SoftwareMaven wrote:
| The first series of courses in my CS program introduced us to
| building a pascal interpreter using scheme. It all depends on
| the pedagogical needs, I suppose.
| psychphysic wrote:
| New comers 5 years experience systems engineering. Just like
| your typical entry level job listing.
| Solvency wrote:
| Seems pretty common to claim <technology X is both easy to
| learn yet extremely powerful>.
| truth_seeker wrote:
| Is the webassembly story ripe yet ?
| manicennui wrote:
| The comments section of this submission are the perfect example
| of how far this site has fallen. Bunch of blub programmers
| worried about whether Racket is the most popular or can be used
| for their crappy day job.
| tgbugs wrote:
| I've been using Racket for about 8 years now, and it is now my
| goto language for anything that needs a gui. It took writing 3 or
| 4 not-so-little guis to feel comfortable working with Racket's
| object system, but now it basically goes at the speed of thought.
|
| Lately I've been using Racket to prototype the interaction design
| for a game, and I had written some placeholder text. I had put
| fake interpolation in for {player-name} and things like that, and
| then I realized that #lang at-exp would let me just ... do that,
| as described in the original article.
|
| I had to laugh, because I maintain a bunch of Python code, and if
| Python has batteries included, Racket comes with a retrofittable
| fusion battery pack.
|
| One other little anecdote, is that I've been porting an old plt-
| scheme codebase to Racket CS. In the second phase I have started
| replacing an ancient C++ rendering layer with the racket gui
| canvas functionality. During the process I moved hundreds of
| runtime type checks in the C/C++ layer to the Racket contract
| system. It was as if the Racket team had somehow secretly
| obtained access to the codebase I was working on and had designed
| the perfect abstractions to solve the problem.
| NickNaraghi wrote:
| The fundamentals of CS courses in my undergrad program were
| taught in Racket (with HTDP). At the time this seemed very
| impractical, because I already knew Java and just wanted to write
| useful apps.
|
| But as I've progressed in my career, I've come to appreciate how
| it helped me develop a strong foundation for reasoning about
| programs and their underlying logic (in any language) that
| continues to serve me to this day.
|
| If I was approaching this outside of a structured curriculum, it
| would be hard for me to justify this long-term intangible benefit
| relative to being able to move quickly to write something
| interesting and useful. And I think writing interesting and
| useful programs is the best way to motivate oneself to keep
| programming. So I can't strongly advocate for this approach. But
| I do think there are some worthwhile benefits.
| nkassis wrote:
| I think it could be argued that the language used in
| universities is unlikely to be the one used professionally. I
| remember when the derogatory term "Java school" was commonly
| used for schools that shoehorned Java in all courses just to
| try to match the language of the day in enterprises. It really
| should be about what is the best pedagogical tool to teach the
| concepts the student is expected to understand irrespective of
| future professional tools used. If racket exposes those
| concepts better without making it onerous on students to learn
| that's great.
|
| When MIT switched from scheme to python for their undergrad
| classes there was a big debate here aboutit. I think the
| argument was that python won't make learning the concepts any
| harder but is less of an issue for students to learn and has
| some long term value professionally so win-win. I don't fully
| agree but I can see the logic.
| timidger wrote:
| It's not (just) that python is "easier" to learn than python
| (which I dispute - lisp is as easy to learn as a first
| language as any other. Depending on the language it may be a
| difficult second language though). The world had also changed
| radically since it was introduced into the curriculum:
|
| "Costanza asked Sussman why MIT had switched away from Scheme
| for their introductory programming course, 6.001. This was a
| gem. He said that the reason that happened was because
| engineering in 1980 was not what it was in the mid-90s or in
| 2000. In 1980, good programmers spent a lot of time thinking,
| and then produced spare code that they thought should work.
| Code ran close to the metal, even Scheme -- it was
| understandable all the way down. Like a resistor, where you
| could read the bands and know the power rating and the
| tolerance and the resistance and V=IR and that's all there
| was to know. 6.001 had been conceived to teach engineers how
| to take small parts that they understood entirely and use
| simple techniques to compose them into larger things that do
| what you want. But programming now isn't so much like that,
| said Sussman. Nowadays you muck around with incomprehensible
| or nonexistent man pages for software you don't know who
| wrote. You have to do basic science on your libraries to see
| how they work, trying out different inputs and seeing how the
| code reacts. This is a fundamentally different job, and it
| needed a different course. So the good thing about the new
| 6.001 was that it was robot-centered -- you had to program a
| little robot to move around. And robots are not like
| resistors, behaving according to ideal functions. Wheels
| slip, the environment changes, etc -- you have to build in
| robustness to the system, in a different way than the one
| SICP discusses. And why Python, then? Well, said Sussman, it
| probably just had a library already implemented for the
| robotics interface, that was all."
|
| https://www.wisdomandwonder.com/link/2110/why-mit-
| switched-f...
| aidenn0 wrote:
| > It's not (just) that python is "easier" to learn than
| python (which I dispute - lisp is as easy to learn as a
| first language as any other. Depending on the language it
| may be a difficult second language though). The world had
| also changed radically since it was introduced into the
| curriculum:
|
| A lot of texts will use pseudo-code and it is (from my
| experience) easier for beginner programmers to see the
| relation between pseudo-code and Python than for many other
| languages.
| lproven wrote:
| > python is "easier" to learn than python
|
| (?)
| pklausler wrote:
| I see this as the distinction between computer programming
| and software engineering.
| agumonkey wrote:
| I'm still surprised Sussman describes the 2000s as a "new"
| job whereas to me it's just mediocre soil from an unstable
| industry. Mucking around is not engineering.. it's alchemy.
| tigen wrote:
| I suppose it depends on what issues we should consider to
| be introductory. Maybe the older theoretical approach was
| more fundamental then than it is now. Like, maybe that
| was effectively more practical given the old hardware
| performance constraints and likely having more control of
| the entire program stack.
|
| It's interesting that Sussman kind of lumps together
| "uncertain software libraries" into the same category as
| machine control robustness (e.g. hysteresis). I never
| thought of it that way but I guess in practice it's all
| just "stuff", those libraries are just another piece of
| your program's environment like any other.
| agumonkey wrote:
| Maybe MIT approaches post 2000 engineering with a solid
| foundation of analysis that creates both a beautiful
| creation process and reliable beautiful software
| artefacts. But what I observe is a never ending stream of
| partial doc reading, partially out of date, with random
| attempts until it looks it won't fail it left running for
| a few minutes.
|
| Ability to deal / reflect with unknowns for engineering
| is of great value, but so far I've never seen that in
| office.
| dreamcompiler wrote:
| The logical culmination is modern ML, where no
| engineering is involved. "If the thing fails on some case
| and kills somebody, train it more." This is voodoo, not
| engineering.
| xp84 wrote:
| When I read things like the second paragraph above, I start to
| wonder if maybe I am actually a terrible programmer because I
| only ever learned what you might generously call "applied
| computer science" aka only the languages commonly used in
| typical workplaces (Java, PHP, Ruby, JS) and none of the CS
| classics. Does anyone else without the so-called 'academic'
| languages foundation ever feel this way when you see people on
| HN always writing about Lisp and its peers?
| gglitch wrote:
| I think I had the inverse experience. I started with Lisp
| because I was customizing and extending Emacs. As I self-
| taught programming from that point forward, most other
| languages have sooner or later frustrated me with
| inexplicable inconsistencies with the syntax and data model.
| Lisp, Tcl, and Prolog all clicked into place quickly and
| easily, and for everything else, I'm constantly referring to
| a guide to the syntax. Not that big a deal, but feels
| internally like at best sort of a head-scratcher.
|
| None of this has anything to do with academic computer
| science. I think I'm just unusually bad at memorizing syntax.
| tigen wrote:
| Chapter 1 of the SICP book says that the main reason it uses
| Lisp is its convenience in manipulating procedures as data.
|
| There is a "JavaScript Edition" of SICP. The preface says
| ECMAScript 2015 enabled a close match by adding lambda
| expressions, tail recursion, and block-scoped variables and
| constants.
|
| It doesn't mention much downside except that JavaScript's
| "rigid syntactic structure complicated the implementation" of
| some programming language design book material.
| ign0ramus wrote:
| You're probably not. Programming in lisp,back in my college
| days, felt enlightening. I remember flying through quiet
| complex projects with a clarity that I've rarely experienced
| in my professional career. I do yearn for those days when I'm
| deep within a nonsensical "enterprise" Java codebase or a
| messy frontend codebase but I don't think Lisp made me an
| objectively "better" programmer. There is enough imposter
| syndrome in this industry as it is. If you ever want to, pick
| up SICP or "How to design programs", you'll probably find
| them interesting but don't expect to find programming
| nirvana.
| zsh_89 wrote:
| [dead]
| vipermark7 wrote:
| I also wish I would have studied classical CS in college.
| However, I was sick most of the time, and there were half a
| dozen weed-out classes, so the computer science courses I did
| take were non-major courses to supplement a GIS degree.
|
| GIS is certainly interesting in its own ways, and it taught
| me some visualization and design skills, but I wish it would
| have been possible for me to learn more of what's going on
| under the hood of the massive libraries and high-level
| languages I use every day as a professional "software
| engineer"
| scj wrote:
| I had the same prof for several courses. His exams were
| pretty straight forward, but always contained a "tough
| question".
|
| In order to get that tough question, you could carefully read
| the book, read his assignment solutions, and pay close
| attention to his caveat warnings in lectures... One of the
| three would typically contain the tough question.
|
| Or, you could just read the book, do the assignments, and
| accept ~95% on the final exam as a maximum grade.
|
| A ~95% cap, for a lot less work, is a good deal. Taking the
| deal is probably the right call for most people.
|
| That being said, the thing I wish someone explained well is
| how amazing lambdas can be. I understood the benefits of
| list/array/stream processing on first glance, but it took a
| few years before I really understood the practical
| application of lambdas.
| 2143 wrote:
| Me too.
|
| So I decided to learn SICP on my own. I already have the
| book, so I'll watch the MIT lectures of the original authors
| available online, and try to make progress.
|
| I'm not in any hurry to complete it anytime soon.
| eyelidlessness wrote:
| I still haven't tried Racket, but I did dive into Clojure. It
| was on the job, not a structured curriculum by any stretch. But
| I can say the same:
|
| > ...it helped me develop a strong foundation for reasoning
| about programs and their underlying logic (in any language)
| that continues to serve me to this day.
|
| I went on to use Clojure and ClojureScript for several years.
| Now I primarily work in JavaScript and (preferably) TypeScript,
| but I can't say a day has gone by where what I learned working
| in Clojure hasn't been applicable and valuable.
|
| Just one more anecdata point, but I would advocate learning a
| lisp--maybe even _any_ lisp. In fact, it's usually one of my
| first recommendations when juniors /mentees ask me for advice
| in any kind of broad strokes.
| theanonymousone wrote:
| Isn't Clojure the literal "Lisp for the modern day(a.k.a JVM)"?
|
| I hope I don't get kicked out of HN altogether for this comment
| :)
| c_crank wrote:
| Clojure is opinionated against using all the potential features
| of Lisp.
| masijo wrote:
| What would be those potential features of Lisp that Clojure
| is missing?
| fulafel wrote:
| It steers you pretty heavily toward functional programming.
| c_crank wrote:
| Multi paradigm support, low level / C interop capacity,
| really any sort of native features
| waffletower wrote:
| Clojure is a multi-hosted language. Clean native interop
| would be nice to have I agree though.
| waffletower wrote:
| That is fair, though not a negative for many. Clojure prefers
| immutable data structures and functional constructs. Rich
| Hickey even wishes that he added fewer OOP constructs in the
| language (such as structs) and leaned more heavily on Clojure
| rooted functional concepts like 'transducers' which came
| later in the life of the language.
| mejutoco wrote:
| IMHO Common Lisp is the modern one. Using the JVM is nice for
| certain uses, and clojure is a fine language, but going bare
| metal from higher abstractions is some power of Lisp that we
| should not give up. Same with macros and code generation.
|
| Luckily all of them can coexist, so we do not need to choose.
| criddell wrote:
| How is code generation handled on modern operating systems
| and CPUs? Isn't there normally a strict separation between
| code and data to prevent exploits?
| andsoitis wrote:
| > How is code generation handled on modern operating
| systems and CPUs? Isn't there normally a strict separation
| between code and data to prevent exploits?
|
| You compile code, which is text (data), all the time, don't
| you?
| Zambyte wrote:
| The difference is that the output of the compiler is
| usually not loaded into the same process that did the
| compiling. That is not the case for applications that are
| developed On Lisp(tm).
| p_l wrote:
| At worst you have to ensure that you separate what needs to
| be writeable from executable, and then flip mappings RW->RX
| when generating new code, just like other JIT compilers do.
| criddell wrote:
| Oh okay. I was thinking of self-modifying, not just code
| generation. That was something that was done occasionally
| by DOS and Windows programmers before the introduction of
| DEP in Windows XP.
| trws wrote:
| Yeah, self modifying has become harder. As far as I know
| the most robust solution to that now is like what Julia
| does, where it can compile new generations of any module
| to update call targets, for example. At worst, when
| seccomp disallows flipping a writable page to executable
| at runtime, you can always compile into a file then
| dlopen the file. In other words, it can take many more
| contortions now than it used to, but it's still possible.
| perihelions wrote:
| I just checked: SBCL on Linux/amd64 puts compiled functions
| in a r+w+x page. You could write Lisp that writes Lisp that
| writes self-modifying machine code, and it would (I think)
| run by default. (compiled-function-p #'f)
| ; T (disassemble 'f) ; disassembly
| for F ; Size: 58 bytes. Origin: #x5350CD14
| ; F ; 14: 498B4510 MOV RAX, [R13+16]
| ; thread.binding-stack-pointer ; 18: 488945F8
| MOV [RBP-8], RAX ; 1C: 4883EC10 SUB
| RSP, 16 ; [...] $ pmap $PID
| --range 5350CD14 442331: /usr/bin/sbcl
| 0000000053498000 122272K rwx-- [ anon ] total
| 122272K
| [deleted]
| archgoon wrote:
| [dead]
| dorfsmay wrote:
| Was lisp compiled code, not code.running in a repl, ever
| able to self modify?
|
| It looks like that wasn't the case even in 1996:
|
| https://groups.google.com/g/comp.lang.lisp/c/O1dDXlQsVkw
| dreamcompiler wrote:
| Self modifying code in the sense of changing one
| instruction to another at runtime (as was commonly done
| in assembler in the 1960s) is not generally possible with
| modern Common Lisps mostly because modern operating
| systems don't allow it. And that's a good thing because
| such code would be hopelessly insecure and impossible to
| reason about.
|
| But if you mean "compile a new function called X and
| replace the old X at runtime", that's easy in Common
| Lisp. It's not commonly done unless you're explicitly
| writing some kind of compiler.
|
| What is commonly done is to create a lexical closure at
| compile time and change its bound values at runtime. IOW
| changing the private _data_ of a function at runtime is
| more generally useful than changing its _instructions_.
|
| What's most common is to write lisp programs that emit
| lisp source code and compile it at compile time (but
| usually not run time). Such programs are called macros.
| pfdietz wrote:
| One can define and compile functions in a running Common
| Lisp. There's a standard function, compile, that does
| this.
|
| In SBCL, any evaluation of an expression is done by first
| compiling it. Compiled functions that are no longer
| accessible (including not having any frames on the stack)
| are garbage collected.
|
| The really interesting question is not whether users can
| mutate existing compiled code, but whether it's useful
| for the Common Lisp implementation to do so. This is
| because Common Lisp is a dynamic language, where generic
| functions and classes can be redefined on the fly. If you
| want to implement such things efficiently, it would be
| useful to be able to change existing compiled functions
| to reflect that (for example) this slot of this object is
| at this offset rather than that offset.
|
| A scheme has been proposed to do that that puts such code
| off to the side in little chunks accessed with
| unconditional branches. When a redefinition occurs the
| branch is redirected to a newly created chunk; the old
| one is GCed when no longer referenced from the stack. You
| have to pay for the unconditional branches, but those are
| typically quite fast.
| waffletower wrote:
| No, 'eval' is available in many dynamic languages and needs
| to be utilized with care
| dom2 wrote:
| There is also ABCL, an implementation of common lisp on the
| JVM https://armedbear.common-lisp.dev/
| waffletower wrote:
| I am curious how performant compiled Common Lisp is compared
| to GraalVM compiled Clojure native images. You certainly
| don't give up macros and code generation when using Clojure,
| though you do give up a specific class of explicit reader
| macros. Some reader extensibility can be had (and is used in
| Clojure.core) via reader functions (data_readers.clj)
| pfdietz wrote:
| You don't give macros and code generation when using
| compiled Common Lisp, either.
| mark_l_watson wrote:
| I agree, Common Lisp is crufty but really stands the test of
| time. I have been using Common Lisp since about 1982 and old
| code still runs fine.
|
| My relative use of Lisp languages: Common Lisp 60%, Racket
| 20%, Haskell 5%, Clojure 5%, and various other Schemes 10%.
| Unfortunately since most of my work in the last 8 years has
| been deep learning, LLMs, LLM chains, etc., I spend a little
| over half my time now using Python. So it goes...
| deckard1 wrote:
| "old code runs fine" is a poor benchmark for how well a
| language holds up over time. All x86 code still runs fine.
| Perl 5 is from, I think, 1994. It's still maintained and in
| development. Most C code from the '80s would still compile
| and run just fine (at least POSIX-based, Windows
| however...). You can trivially find Pascal, Fortran, COBOL,
| and Forth code that all "still runs fine."
|
| I don't think it's a particularly unique or interesting
| quality, that some old code still runs. After all, I can go
| to archive.org right now and run all of that ancient DOS,
| Amiga, whatever code in a 100% exact (or close to) emulator
| in my browser.
| i_am_a_peasant wrote:
| That Vonnegut reference at the end ;D
| wildermuthn wrote:
| Unfortunately, IMHO Clojure's maintainers hold an iron grip on
| the language and actively limit the growth of an ecosystem
| around it. See "Open Source is not about you".
|
| It's too bad, because itself is really terrific.
| waffletower wrote:
| The iron grip is on a decidedly double-edged sword. I applaud
| the continuity and maintainability of Clojure and its
| ecosystem. The consistency of the language has come from this
| stern stewardship. Rich makes very clear that the source code
| for the language is available to be forked. Very interesting
| developments have come from this, most notably babashka.
| fulafel wrote:
| I think being conservative about evolving the language, and
| ecosystem growth are mostly different issues, the open source
| post was about the core language.
|
| Comparing to other languages I think the stability of the
| language has served the user community really well and been
| an enabler of the ecosystem. I guess the continuous language
| additions and resulting complexity & library/framework chuirn
| in some otherlanguages can also be seen as vitality and
| growth, but for many of us it's the wrong kind of growth.
|
| (And yes there are also disadvantages to the centralised
| development model of the core language)
|
| edit: there's a good summary of the discourse surrounding
| this post in the reddit comments at the time: https://www.red
| dit.com/r/Clojure/comments/a0pjq9/rich_hickey...
| wartijn_ wrote:
| Link to Open Source is not about you: https://gist.github.com
| /richhickey/1563cddea1002958f96e7ba95...
| pjmlp wrote:
| To their right, Rich Hickey almost got bankrupted while
| developing Clojure.
|
| The usual "expect all for free, give nothing back" attitude.
| threatofrain wrote:
| Rich Hickey basically wrote this in response to one of the
| notable and respected contributors of his ecosystem. If
| Rich wanted open source to be nothing more than a license
| and delivery mechanism then he shouldn't have accepted
| volunteers. But a language without an ecosystem of
| volunteers is a dead language.
| pjmlp wrote:
| Many languages do quite well as commercial products.
| erichocean wrote:
| Clojure "the language" is certainly ossified, but Clojure
| "the ecosystem" is doing very, very well.
| nocman wrote:
| I'm genuinely curious. What about the language do you
| feel is "ossified"? I am interpreting that as being a
| negative description.
|
| Stability is extremely valuable. A lack of change to the
| core language over extended periods of time can be a very
| good thing, especially if certain changes would break
| existing code. Rich has made it clear that he is indeed
| targeting this kind of stability.
|
| Again, I would be very interested to hear what specific
| changes you think need to be made to 'Clojure "the
| language"'.
| erichocean wrote:
| No changes, I'm a happy Clojure user. Long-term stability
| is one of its selling points.
| systems wrote:
| the problem with clojure is you have to learn java (or at least
| some java) same issue i see with F#, you still need to have at
| least some basic knowledge of C#
|
| unfortunately running on JVM actually really means running on
| Java same for .net it mean running on C#
|
| i dont mind learning two languages, its expected from most
| developers to know more than one, but context switching in a
| single function between two language is not fun
| pjmlp wrote:
| The curse of guest languages.
|
| However F# suffers from a bigger issue, that clojure doesn't,
| belonging to the platform owner, that behaves as if it was an
| error to make it part of VS 2010.
| jeremyjh wrote:
| Isn't that because F# failed to win any significant market
| share? I think F#'s problem is that C# is too good and this
| was true even in 2010, its not like Scala vs. Java in 2010.
| systems wrote:
| F# is way nicer than C# (and Clojure is still way nicer
| than Java)
|
| And I dont think F# failed, I just think it needs to find
| a way to hide C# and OOP better
|
| But the language is doing fairly well, tons of
| educational resources, tons of videos on youtube ,
| several nice projects on github, solid vs code mode, it
| is part of .net , but still a lot can be improved, and
| microsoft is far from abandoning, C# is one of MS
| flagship products , F# is not a flagship product
|
| And I also think that Don Syme is a lot more active
| working for F# and promoting it, than Rich Hickey is
| currently working for Clojure
| soulbadguy wrote:
| Big F# fan here, but i don't really "doing fairly well"
| is a fair assessment of the F# ecosystem right now.
|
| > microsoft is far from abandoning
|
| Might has well. When you look at the resources actually
| being deployed for F#, it's clear that MSFT either don't
| care or don't really have plan for F#. Most of the work
| is done by the community. The number of actual paid/full
| time MSFT dev on F# is very limited. The tooling is
| extremely limited, there is no official F# libraries for
| pretty much any MSFT and azure services (have to relie on
| C# libs.) In leetcode where the have C# (so already have
| the infra to run .net stuff, and language like elixir and
| racket (so they do have more niche language), they still
| don't have F#.
|
| The salvation for F# would come from finding a killer
| app, something akin to pytorch/numbpy or rails.
| trenchgun wrote:
| Killer library. Not an app.
| josephferano wrote:
| I worked with F# for about 3 years and the sentiment of
| most F# developers after using it in anger, including
| myself, is "I don't want to go back to C#". In my
| opinion, it didn't win significant market share because
| Microsoft didn't want it to. This goes even further back
| than 2010. I don't know if it's because F# was open
| source and C# was not, as Microsoft's FOSS stance hadn't
| really come around yet till what, 2016?
| guhidalg wrote:
| Maybe, and it's a good case study to compare F# vs. C#
| with Java vs. Scala to understand why Scala seems to have
| higher penetration than F#.
|
| In my opinion, and I mean this in the broadest way
| possible, the average C# developer is probably less
| motivated to learn a new language than the average Java
| developer. That's because C# developers are prescribed by
| Microsoft what to do, and Microsoft could deliver a
| productive-enough experience with C# + .NET Framework +
| Visual Studio for a long long time.
|
| Java's fractured IDE story and runtime (OpenJDK vs.
| HotSpot) I think lead to a higher concentration of
| programming language people looking at the JVM as a
| viable target to build a better experience on top of, so
| we got Groovy, Scala, Kotlin, (anyone remember Xtend?),
| IDEA, Eclipse, etc...
|
| The bazaar produced and embraced a functional programming
| language whereas the cathedral treats F# as thunderdome
| for new C# features.
| Capricorn2481 wrote:
| Scala pretty much hangs on a thread and is only breathing
| cause of Spark
| bmitc wrote:
| Reading C# code makes me shudder. It is so hard to read
| with all the brackets, spacing, indentation levels, and
| overall verboseness. I honestly don't know how people do
| it.
|
| F# can do OOP just as well if not better than C#, and F#
| is anywhere from 2-10 times more concise than C#.
|
| That being said, the mistake of Microsoft was viewing F#
| as a competitor to and research lab for C# and the
| community for viewing and selling it as a replacement for
| C#.
|
| What Microsoft and the community should have done is
| treated F# as a competitor and replacement for Python
| from the start.
| pjmlp wrote:
| That is what F# folks tried to pivot the language as of
| latest, only to be sidestepped yet again by Microsoft,
| when they hired Guido and managed to be the company that
| changed his mind regarding CPython optimizations.
|
| Also see the development effort Microsoft spends on
| Python across all their IDEs and what F# gets.
| deckard1 wrote:
| > The curse of guest languages.
|
| Every language lives under the iron fist of libc and the C
| ABI.
| pjmlp wrote:
| Not every OS is an UNIX clone.
| bmitc wrote:
| You really don't need to know C# to use F#. You need to
| understand .NET, but that is not the same as needing to know
| C#. F# sits on top of .NET and the CLR in a much more clean
| way than Clojure sits on top of the JVM. F# also has
| excellent error messages and is also much easier to install.
|
| I know F# quite well at this point but only barely know C#. I
| know C# maybe only mildly better than C++ or Java in terms of
| being able to read it and guess what it's doing. I certainly
| can't write in it without looking up a bunch of stuff.
| Capricorn2481 wrote:
| Aren't most libraries you want in C# though? Isn't there a
| bit of impedance mismatch between how functional F# is and
| how OOP C# is? I have heard from a few F# fans how
| frustrated they are that they have to keep interacting with
| C#
| nifty_beaks wrote:
| I recently did a small project in F# just to try it out.
| This was my exact experience. Syntacticly it seemed very
| nice and in some ways it was cool to have all the
| libraries I'm used to in C#, however due to the latter it
| ends up being possible to suddenly have `null` or other
| weird non-functional thingies suddenly pop up.
| [deleted]
| phtrivier wrote:
| "It can generate an executable" ; but how slow will this
| executable be ? Compared to something compiled with SBCL or a
| non-LISP ?
| [deleted]
| f1shy wrote:
| Also how big will the exe be. Last time I looked the whole
| interpreter is packed together with the source. Also I'm not
| sure if you can obguscate the code, if you do not want to
| publish it.
| macco wrote:
| Probably, it will be fast enough. The new compiler is based in
| mzscheme.
| ObscureScience wrote:
| Isn't Chez Scheme the default runtime by now?
| Jtsummers wrote:
| Yes. Since 8.0.
| ryanschaefer wrote:
| A while ago I wrote an AWS lambda runtime to use Racket. I saw
| terrible Startup performance at around 500ms for a simple echo
| program.
| dchest wrote:
| Yeah, reading all those parentheses on startup is not fast.
|
| As an anecdote, I used to host a computationally expensive
| web app written in Racket (even before Chez version) serving
| large amount of requests at peak times on a single $10
| DigitalOcean droplet. It was pretty fast and didn't crash. No
| need for awkward modern web scale thingies.
| velcrovan wrote:
| Is the parentheses comment a joke?
| dchest wrote:
| Yes :) I don't think there are many of them in a simple
| echo program, and I guess the runtime is compiled when
| it's shipped.
| andsoitis wrote:
| > AWS lambda runtime
|
| l most of the way down.
| waffletower wrote:
| Are you aware of AWS lambda warm starts? Start-up time can be
| less critical should the lambda be used frequently enough. ht
| tps://docs.aws.amazon.com/lambda/latest/operatorguide/exec...
| p4bl0 wrote:
| Racket executables are not to be compared with those of a
| compiled language that aims for speed. The primary goal is not
| speed here and the documentation explicitly says so. You should
| see them as _interpreted_ code that is bundled with its
| interpreter for easier distribution and execution, without
| anything else to install for end users.
|
| You can write a Racket application even with a GUI and whatever
| lib you need and then cross build it as a native executable
| (that is, an executable that embeds the interpreter, the
| necessary libs, and your application's code) for yours and
| other platform for easy distributions.
|
| See https://docs.racket-lang.org/raco-cross/index.html and
| https://docs.racket-lang.org/raco/exe.html for more
| information.
| tmtvl wrote:
| > _The primary goal is not speed._
|
| But the authors states that Racket is " _the finest example
| of a modern day lisp bar none_ ". In the _modern day_ energy
| efficiency and climate change are major issues, the German
| government, for example, has set up the Blue Angel Ecolabel
| program: <https://www.blauer-engel.de/en>. Using _modern
| day_ to mean VSCode and Discord is a worthless use of the
| phrase.
| p4bl0 wrote:
| I don't know the numbers but I can probably agree that
| "modern day" can be replaced by "batteries included" and it
| would be a better description, from the (valid) point of
| view that you take.
|
| However, Racket is also a modern language in that it has
| many new and fancy programming language research-grade
| features since it is also a programming language theory
| research platform. From that point of view, "modern day" is
| a valid description :).
| mcpackieh wrote:
| Generally, don't take puffery literally. And whenever the
| author of this random blog seems to contradict the
| documentation, you can safely assume the Racket
| documentation is more authoritative.
| [deleted]
| andsoitis wrote:
| According to https://stratoflow.com/efficient-and-
| environment-friendly-pr...
|
| Racket ranks far ahead of languages like TypeScript,
| Python, and Erlang in terms of energy usage, but trails
| languages like C, Rust, Ada, Java and Common Lisp.
|
| I think, however, there are probably other factors in your
| computing solution that has a bigger energy impact, like
| what processors you run on, the architecture of your
| program, etc.
| BackBlast wrote:
| How can you trust a list that places JavaScript an order
| of magnitude lower than TypeScript? Seems fundamentally
| broken.
| badsectoracula wrote:
| I didn't read the original paper[0] but it is based on
| the Debian Benchmark Game[1] as it was in 2017 and the
| game relies on user submitted code for each language
| separately, so most likely when the researchers checked
| the results, the TypeScript tests didn't have as
| optimized tests as the JavaScript tests - which makes
| sense as the latter is way more popular than the former,
| so there are less people to bother with it (and in fact
| the benchmarks nowadays do not include TypeScript at
| all).
|
| You can confirm it via archive.org too: the TypeScript[2]
| page shows both less implementations and the
| implementations that are shown are often slower than
| those in the JavaScript[3] page.
|
| As for if that makes sense, well, IMO using the benchmark
| game for judging how good a language is at optimizations
| is flawed in the first place as not only there is a bias
| towards the more popular languages but also a lot of the
| top entries use approaches that in practice you wouldn't
| find in real projects.
|
| [0] https://greenlab.di.uminho.pt/wp-
| content/uploads/2017/10/sle...
|
| [1] https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
|
| [2] http://web.archive.org/web/20170425064751/https://ben
| chmarks...
|
| [3] http://web.archive.org/web/20170425114504/https://ben
| chmarks...
| IshKebab wrote:
| I fixed the Typescript implementation 3 years ago when
| this paper was debunked back then.
|
| Didn't submit it though because they make it difficult.
|
| https://news.ycombinator.com/item?id=24826453
|
| (the whole thread is worth a read)
| igouy wrote:
| And-yet your program was accepted and included, and then
| with a later TypeScript update it stopped working.
| spectralnorm.typescript-6.ts(115,29): error TS2794:
| Expected 1 arguments, but got 0. Did you forget to
| include 'void' in your type argument to 'Promise'?
|
| Something like that is probably what stopped the authors
| of "Energy Efficiency across Programming Languages".
|
| https://sites.google.com/view/energy-efficiency-languages
| IshKebab wrote:
| Yeah Typescript doesn't guarantee perfect backwards
| compatibility. You normally have the compiler as part of
| your dependencies and pin it. I guess they just didn't
| know.
|
| I don't know what you mean with your last sentence.
| That's the same paper...
| BackBlast wrote:
| I appreciate the thoughtful reply. Every time I see this
| list trotted out I can't get past the obvious red flag.
| Nice to have some more background on it.
| igouy wrote:
| --alwaysStrict
|
| So when the JavaScript doesn't type check, the authors
| measured a different program that does type check.
|
| Even so, that only messes up the results because the mean
| is used rather than the median, and the data tables
| published with that 2017 paper, show a 15x difference
| between the measured times for a single outlier the
| selected JS and TS fannkuch-redux programs.
|
| That single outlier is enough to distort TS and JS "mean"
| Time difference.
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| igouy wrote:
| A single outlier is enough to distort the TS and JS
| "mean" Time difference.
|
| https://news.ycombinator.com/item?id=36524073
| badsectoracula wrote:
| Check the pages i linked at, or even better the one that
| compares the two[0] around 2017. While there is a single
| case with _wildly_ different results, there is more than
| one with results that also have a large difference in
| JavaScript 's favor.
|
| [0] http://web.archive.org/web/20170715120019/http://benc
| hmarksg...
| igouy wrote:
| Please read the original paper and base your comments on
| the repo that the authors provided.
|
| Like you, most readers haven't seen the paper.
|
| Like you, most readers have only seen "Table 4.
| Normalized global results for Energy, Time, and Memory"
| taken out-of-context (often without any way to find the
| original source).
|
| Most readers notice the too-large differences C/C++ and
| JS/TS and start speculating about how those differences
| were caused (because that's fun).
|
| I went back to the time measurements the authors provided
| and calculated the Mean, Geometric Mean and Median.
| Simply using a more appropriate summary statistic would
| have presented average values which readers would have
| found acceptable: JS 7.25 times slower
| than C TS 7.8 times slower than C
|
| :even though they were based on different programs and
| included an outlier. (Similar story with C/C++.)
| andsoitis wrote:
| > How can you trust a list that places JavaScript an
| order of magnitude lower than TypeScript? Seems
| fundamentally broken.
|
| The list places JavaScript at a score of 4.45 and
| TypeScript worse at 21.5. For reference, C, the most
| energy efficient it 1.0
| igouy wrote:
| The authors chose to summarize their data using the mean,
| and that highlights the variance.
|
| Using the Geometric Mean or the Median with the time
| measurements from that table would have highlighted the
| middle value, like this: JS 7.25
| TS 7.80
|
| https://benchmarksgame-
| team.pages.debian.net/benchmarksgame/...
| BackBlast wrote:
| > The list places JavaScript at a score of 4.45 and
| TypeScript worse at 21.5. For reference, C, the most
| energy efficient it 1.0
|
| The point is that TypeScript is JavaScript with typing
| syntax added on top. There is a transpile step into JS.
| That's how TypeScript works. The runtimes are exactly the
| same. Unless we're also measuring the build step? Which
| seems silly.
|
| The difference should be near zero. And it's not. They
| clearly do not understand exactly what they are
| measuring.
| soegaard wrote:
| I don't know what the usual speed difference of
| TypeScript programs vs JavaScript programs.
|
| But the argument that TypeScript generates a JavaScript,
| so it must have similar speed doesn't hold in general.
|
| If the compiler in question is a whole-program compiler,
| it can make optimizations that a normal person couldn't
| do.
|
| As an anecdote in [1] a raytracing program were
| implemented in both Scheme and C. The Stalin compiler (a
| whole-program Scheme compiler) produced an executable 45%
| faster than the one produced by g++. The Stalin compiler
| produced the excecuable by compiling Scheme to C, and
| then used a C compiler to produce the final executable.
|
| The price of a whole-program compiler? Well, the compile
| time are huge.
|
| [1] Scroll to Siskind's comment. https://groups.google.co
| m/g/comp.lang.scheme/c/NJxRsdMNKz4
|
| For those curious about the actual programs and results:
| https://web.archive.org/web/20071011073406/http://www.ffc
| ons...
| [deleted]
| andsoitis wrote:
| One explanation is that the typical JS output by the TS
| compiler is more verbose (so more code to load, parse,
| and run). On the other hand, one can imagine that the TS
| compiler's catching classes of errors at compile time
| means fewer runtime exceptions.
|
| I think the takeaway, however is the theme of a spectrum
| of energy efficiency, with compiled languages being more
| efficient than those that are not.
|
| But I still maintain that the overall efficiency of a
| system is more a function of other factors.
| BackBlast wrote:
| My take away is that this list is very unreliable.
| igouy wrote:
| > with typing syntax
|
| Programs that didn't type check were excluded.
|
| https://github.com/greensoftwarelab/Energy-
| Languages/issues/...
| lispm wrote:
| > Racket executables are not to be compared with those of a
| compiled language that aims for speed.
|
| https://docs.racket-lang.org/reference/implementations.html
|
| "The CS implementation is the default implementation as of
| Racket version 8.0. This variant is called "CS" because it
| uses Chez Scheme as its core compiler and runtime system.
|
| The CS implementation typically provides the best performance
| for Racket programs. Compiled Racket CS code in a ".zo" file
| normally contains machine code that is specific to an
| operating system and architecture."
| maroonblazer wrote:
| I've started working through "How To Design Programs" and it
| calls for using DrRacket. It didn't occur to me to see if there
| was support for Racket in VSCode. Per this article, there is, via
| extensions.
|
| For anyone who has worked through HTDP: is there any benefit to
| sticking with DrRacket vs using VSCode? The friction involved in
| moving around in DrRacket really dampens my enjoyment of the
| material in HTDP.
| soegaard wrote:
| I recommend using DrRacket for the first two weeks. And use it
| when you are working with picts.
|
| Note that you can change the default settings to be more Emacs-
| like.
| i-am-gizm0 wrote:
| My intro CS class was in Racket. Probably 99% of people used
| DrRacket and were fine with it (to be fair that was the _you
| haven 't really programmed before_ class). I had to use it for
| some of the graphics assignments and it's... fine? If you're
| going to keep using it, make your life easier and use a proper
| monospace font (like Consolas). The default (I think Cambria?)
| doesn't align parentheses and brackets with each other and it
| makes it hard to read (at least for me).
___________________________________________________________________
(page generated 2023-06-29 23:01 UTC)