I've been making a language called TXR for ... oh, ten years this coming August now. It combines a Lisp dialect ("TXR Lisp") with a whole-document pattern-based extraction language ("TXR Pattern Language"). It takes the form of a simple executable with a few satellite files in your /usr/share.
Lots of "batteries" are included in TXR Lisp: object system with static and instance slots, single inheritance, GC finalization and a form of RAII, exception handling, delimited continuations, byte code compiler for virtual machine, file compilation, macros (of course), regexes, built-in lazy lists, a fantastic set of macros for partial application, a comprehensive declarative FFI, good amount of POSIX wrapage built-in, a decent REPL with history, completion, multi-line editing, visual copy-paste, ...
TXR Lisp has a concept similar to CL's "generalized places" implemented differently. It supports Lisp-1-style evaluation (higher order functions used without a funcall operator), in the middle of a Lisp-2 substrate. Traditional list operations are generalized so they work on other sequences; you can mapcar over a string and such.
First of all, thanks for doing this and making it free.
I do a lot of shell based work (Linux commands, Awk, Python, Perl, and Powershell) and Lisp has always interested me, so this may scratch an itch.
How easy is this to get setup? Just a few binaries?
Also, one barrier to me has always been learning lisp as it is very different from most traditional scripting languages. I took a look at your examples and it looks neat, but a little complex. Is there a tutorial document that goes over the main functionality and commands. Like with Linux, knowing grep,cut, sort, uniq, cat, and a few others can take you a long way. I should add that although I haven't coded enough lisp to get competent, I've read two books on Common Lisp and have played with Chez Scheme, Racket, and Clojure...so I get the concepts with CONS/CAR/CDR...macros...etc.
> How easy is this to get setup? Just a few binaries?
From sources, just unpack, ./configure (with --prefix=/your/dest/dir if you don't want it in /usr/local/bin), make, make tests, make install if you're going from source. The dependencies are very low. But one of them is libffi; ./configure doesn't complain about it missing, but you get a build with reduced functionality (which doesn't pass certain tests).
For every release I make tarball packages for for older Debian 5.x (64 bit), Ubuntu 12 (32 bit), Mac OS 10.7.4 (64) and Solaris 10 (x86, 32 bit) as well as Cygwin (32 and 64).
For native Windows, I make a installer. It registers TXR into your PATH environment variable and associates .txr and .tl file associations.
TXR installations are relocatable: TXR discovers its own path and then finds the satellite files relative to its own location; if you keep the relative locations of the pieces as they are, you can move it anywhere in your filesystem. That's also useful for deployment. In the TXR executable there is a 128 byte space where you can embed command-line arguments to the executable. There is a helper function for this called save-exe. https://www.nongnu.org/txr/txr-manpage.html#N-02850687
If you've read books on Common Lisp, you're in pretty good stead. My own Lisp background is heavily Common Lisp, and the CL influences in TXR Lisp are clear; yet it's not CL and will probably mess with your head if you know a bit of CL in ways that it wouldn't if you didn't know CL. The reference manual has some dialect notes in relation to CL, far and few between though.
I don't have a newbie tutorial, unfortunately; I'm hoping someone else will write that. Keeping the documentation complete and at a good level of quality has been a big effort; it's pushing close to 700 pages now if PDF-ed.
I'm quite satisfied with it. I put time into it that I was able, and no more than that; and for that time put into it, it is good.
I have a private TODO list, in point form, that is over 1300 lines long, so there is no shortage of stuff to do.
There was never supposed to be Lisp dialect, object system, FFI, or any of those things; it really was just a specialized text extraction tool.
A decade and 5200 commits later, it's interesting that I'm the only contributor (of any logic). There have only been doc fixes.
I also didn't think that a decade later, there would be more than 5200 commits, almost all of them from only me. There have been only some half dozen contributions from outsiders: most of them documentation issues, and something in the configure script. Third party code I've brought in, of which there isn't much, I took over as if they were my own. I've kind of gotten used to it being that way; if that ever changes, it will be big adjustment from "everything here is mine".
Racket is great if you are looking for a high quality general purpose language, but if you want to use important python libraries for pythons's popular use cases: numerical/scientific computing, data science/ai, etc., then Hylang is a drop-in replacement with the added benefit of Metaprogramming facilities (Lisp-2 macros) and Clojure-like semantics.
Python and Hy have 100% interoperability. Python can call Hy out of the box, and Hy can call Python out of the box.
Any Python programmer can pick up Hy basics in minutes, and will be productive in a matter of hours. If you are an intermediate level Python programmer and have experience with Lisp macros, you will be writing macros in no time as well. Writing macro wrappers for numerical/scientific applications can increase your code's signal to noise ratio by quite a lot.
Actually Hy is mentioned in the article, though the author found it didn't fit his usecase.
> Alas, Hy didn't really reach my dream. That macro expansion made debugging a nightmare as Hy would lose track of where the line numbers are; it wasn't until that when I really realized that without line numbers, you're just lost in terms of debugging in Python-land. That and Python didn't really have the right primitives; immutable datastructures for whatever reason never became first class, meaning that functional programming was hard, "cons" didn't really exist (actually this doesn't matter as much as people might think), recursive programming isn't really as possible without tail call elimination, etc
Debugging macro expanded code is definitely the number one pain with Hy, although a somewhat workable solution is to view the output of hy2py (comes with hy).
As far as the lack of functional programming semantics go (no tail call elimination is very sad indeed), there is no denying that either, but considering the applications I am recommending (c/c++ inter-op with python wrappers), you are hardly working in a functional domain in the first place.
A big use case for python is glue for high performance c/c++ code. How is racket at this? Also, is there a cython alternative for racket? I would also argue that, though racket may have more batteries included, there are definitely not as many externally developed libraries. Especially important are numpy/scipy/pandas/pysam, the list could go on...
That's not to say that I'm against racket, I really like the language and its level of design and documentation.
I've used the Racket FFI for some important tasks, and it's very easy to use. However, it's not as fully baked as the Python one (I've found bugs due to GC interactions) and it's weirdly slow (a few too many levels of wrapping). That said, I still use Racket extensively and enjoy it.
This is the write up I was looking for as this is the use case I've had in mind for Racket of late after reading Felleisen's LOP paper.
Would love to know more about your experiences with doing Racket FFI. How hard were the bugs around GC to discover and workaround? What were you building in Racket?
See my responses to a sibling comment for Github bug reports. I had a great experience with them: very fast triage and fixes, plus a lot of help developing a workaround so we could target a range of Racket versions. (Distros still ship some old versions!)
These bugs were found while working on Herbie <http://herbie.uwplse.org/>. We use the FFI to bind to your machine's math libraries so we can properly evaluate how accurate a floating-point expression is on your machine.
There were workarounds (in Racket you can instruct the GC not to move your FFI objects) and I believe the underlying issues have been fixed.
I must add that I got immediate and comprehensive support from the core developers, who not only fixed the bug but also suggested the workaround (so I could continue to support all our target versions of Racket).
While it's nowhere near as mature as Racket, those interested in this use case might also be interested in Clasp, a Common Lisp implementation built on LLVM specifically to enable the combination of Lisp-style dynamic development approaches with C++ libraries.
FFI into C++ is a lot of work in any language. A lot of projects just define a plain C wrapper for the C++ code they want to call, and call that C code from whatever their glue language is.
However, Python does have CLIF[1], which is the nicest solution for calling into C++ that I'm aware of.
I think the biggest thing, for me is Cython. I've not seen anything quite like it in other languages. It allows you to compile python code to c, with gradual typing. It also allows you to write c code inline w/ your python or interface with other C/C++ libraries. https://cython.org/ Other languages will be pressed to beat its utility (esp in the scientific computing world)
pybind11 is a modern version of the Boost Python approach to Python bindings. Header only and can be installed trivially from PyPi.
I like it well enough that I even use it for binding C code. Especially because it has nice numpy array support (albeit a little underdocumented).
It’s the 80:20 rule, which naturally doesn’t always holds. Often, however, a small part of the code is responsible for almost all of the performance issues.
By picking the performance sensitive areas of the program to code in C one can often code the rest of the program in a slower more convenient language.
I hope this year it's videoed well. In past years except the last it's been fine, but last year I'm guessing whoever normally does it wasn't available for 2018.
It's one person doing the recordings and has been the same the last few years iiuc. They were just under-resourced I believe, and last year especially. They're doing a damn good job given the constraints they've been putting things together under I think.
While I'm impressed with racket on the whole, I can't quite agree to be impressed by the GUI bits. They're extremely limited, and once I got away from "how do I put a button on the screen" I didn't find the underlying implementation lent itself to being extended. In particular the drag and drop system only goes as far as file drops, and I quite quickly hit a brick wall trying to add anything more interesting.
In principle you can get pretty far with racket/gui despite it's limited amenities because you can roll your own widgets with canvas. However I too ran into wanting to create a drag source (not merely target) for files and couldn't find a reasonable way.
To be honest though, I think the biggest missed opportunity in racket is the single dispatch object system, used particularly by racket/gui. For some reason the core racket folks weren't smitten with CLOS and didn't go the Guile route of implementing something similar to it (Guile has GOOPS, which is related to Tiny-CLOS.)
The Racket class system has seemed fine to me for the GUI tookit (except for me not liking typing `send`). But if you find a limitation for that purpose, please post about it on the `racket-users` email list. The core developers are there. https://groups.google.com/forum/#!forum/racket-users/
FWIW, Racket (when it was still PLT Scheme) got a tiny-CLOS-alike around the time that Guile got GOOPS: Eli Barzilay made Swindle: https://docs.racket-lang.org/swindle/
CLOS is neat, and I'd be interested to see someone make a CLOS (maybe including a MOP?) for Racket, atop the modern Racket `struct` and other features. (If you tune it, try tuning for the tentatively forthcoming Chez backend to Racket, rather than for the current JIT. IIRC, Swindle was written before the JIT.)
Yeah I don't use racket's class system on a regular basis for anything other than racket/gui. It's not so much that I find myself unable to do things with it; it's just that it's one of the cases where racket seems dull and uninspired. If it weren't single dispatch, I don't think I (and others) would avoid it so much.
No offense to the design team intended, I'm sure they had different priorities for which single dispatch made sense.
I agree. Almost all class systems now are rehashes of things that are useful and were once very exciting, but now you've seen them in tens of languages.
When you encounter yet another one, learning it is usually a matter of seeing which set of semantics it provides (probably all of which you've seen before), and the exact way they do it.
Tk from python is pretty damn convenient, being as it's always there. Not the most modern toolkit for sure, but always being there is a pretty compelling feature for some GUI projects.
Since it came up, Tkinter's drag and drop story is pretty grim too.
I've used Tkinter with python to make a whole bunch of quick utilities (sync tools for non-techies, XML editing stuff for file applications which lack needed tools, etc.) and think it's very under appreciated.
Thanks - I actually meant PyQt5! I don't know where PyQt3 came from... probably related to only finding info on specific functions often leading me to Qt3 docs.
On which platform/hardware is 100MB ridiculous? I was using it on my Raspberry Pi with a 32GB MicroSD card which cost ~10€ for the High Endurance version (officially supported by SanDisk for Linux/Pi) i.e. 100MB is peanuts.
Also the difference between 60MB and 100MB isn't huge, so using the word ridiculous is IMO a bit over-dramatic.
On whatever platform. Requiring a user to download and install a 100MB+ framework just to show a basic GUI is just ridiculous. Even Sublime is 33 MB and I see that as bloated, and that's including its separate copy of Python itself...
I am always confused when people talk about the language itself.
In my experience, python is used for Tensorflow, or Pandas, or Django, or Flask, or pytorch or something else that runs on top of it. Sometimes it is even more specialized and I need a wrapper for an API to let me talk to some web data. Maybe I need a crawler/scraper and a parser. There is a specialized language on top of the language.
So when someone says, oh this language is better with objects, or has some syntax thing or the other, or I can reason about it I am left confused.
Its like if I were talking to a professional shoe designer and I ask for hiking boots and they tell me that they're really into having at least two tones to offset the lace and the heels or something.
What am I missing? I want to reason about the language too, but doesn't that pale in comparison to being able to run a specialized library?
You're missing that people write mountains of code in Python and similar languages; they are not always just for a small amount of glue to gain access to some specialized libraries.
Well, I assume people write mountains of code in the library. If you're making a machine learning product, that is still a lot of work.
However, writing your own Tensorflow interface would take several human lifetimes to get it right, and Google already has provided it. So it seems that is not the part you would re-write no matter how good the language is.
> In my experience, python is used for Tensorflow, or Pandas, or Django, or Flask, or pytorch or something else that runs on top of it.
Is this your experience of using python or reading about it? I don't know your background so I apologize for making some assumptions about the source of your confusion. It sounds like you don't have a ton of experience programming, so let me start with a broadly: Python is a language in sense that English is a language, but these "something else that runs on top of it", are more like specialized vocabulary or jargon than "languages on top of the language".
English gives you the grammar/structure/spelling to communicate; it's a foundation. But it also gives you general vocabulary; adjectives and adverbs blend and interact with any new vocabulary that might come into play. It doesn't matter if its a poem, or novel, or a technical documentation, or a text book, there is still a lot of English-ness to it.
In the same way, Python as a language is still the substrate that each of those tools (Tensorflow, or Pandas, or Django, or Flask) are interacted with. I agree with what you're getting at, that maybe the tools are more important than the language. When people talk about their like for python the could talk about either: the language itself or the culture/ecosystem around the language. Some inherent to the language, so a quirk of it's history.
This applies as much to natural language. You might hear someone love the sound of Spanish or French, or praise the regularity of Latin spelling, or love Greek for the wealth of ancient, influential texts that it gives access to.
In the case of python you get a lot of praise from both angles. People love the language for it's ecosystem, sure; but also for how it does white spacing, its brevity, the specifics of its typing, where it does and dosn't need parentheses, REPLability, etc.
I am not offended that you think I may not program. That is fine. (I mean less than some, more than others. I have coded up the examples I brought up.)
But you haven't responded to the argument. If someone urges you to use Racket, and you have task in front of you (say, put up a website), it sort of matters whether Racket has a framework more than if it has brackets, indents or curly braces.
> What am I missing? I want to reason about the language too, but doesn't that pale in comparison to being able to run a specialized library?
> But you haven't responded to the argument. If someone urges you to use Racket [...] it sort of matters whether Racket has a framework [...]
I guess I misunderstood the question; I didn't realize you were making that argument rather than the actually wondering what other thing people care about. I guess the more direct answer would be that questions like "doesn't that pale in comparison" and "it sort of matters" are kinda presumptions about the motivations of a person "who urges you to use Racket".
Articles like this are as much targeted towards "end-user" programmers as they are for the programmers who built the frameworks in the first place. Flask, Django, etc. exist because people that like Python for things like "if it has brackets, indents or curly braces" wanted those tools in that language.
That's what I was trying to get at before: different people are excited by different things (obviously) but that languages absolutely have draws independent of tools that exist in it. Not for everyone, but not for nobody neither.
Machine learning is a slightly unusual case with powerful important libraries doing the work, with the language on top just being used for orchestration, data loading etc. If that's what you're doing, then you're right, the ML framework availability is far more important.
That's a still a relatively small corner of programming in general though. For most languages when talking about libraries we talk about the 'ecosystem' - what is the availability and quality of all the bits and pieces that we can build upon. It's a question of many small things, rather than one large thing.
Ecosystem differences are less absolute than 'has tensorflow', and so can be weighed up against other language advantages and disadvantages.
Web frameworks are an interesting case because you (usually) don't use them as simple libraries. The interaction with them tends to be complex enough that good frameworks are built around what the language is good at. If the language is right for the sort of programming you want to do, then the framework will express that.
The amount of code available, and its quality, is one aspect of a language's ecosystem that most people take into account when discussing its merits.
It's quite possible to also discuss the language itself independently of how much code is available for it, while acknowledging that it's an important factor for many people.
Flask equivalents exist in every language. Tensorflow bindings are available in many. Pandas is more specific to Python, but using dataframes in Python vs R vs Julia each has a different feel.
I've found that Typed Racket is still fairly hard to use. For example, type classes aren't there, and type polymorphism interacts poorly with general-purpose functions like "equal?". I would guess that ML or Haskell code translates fairly naturally, but there aren't the guide-rails those languages have to keep you in the subset of the language that type-checks well.
when i went through the coursera course "programming languages", i did part a in standard ml (what the course uses) but also in f# and in typed racket (using racket's pattern matching). the code was practically identical across all three languages. now, that's for someone simple programs, but i was surprised that the translation from two MLs was basically trivial to typed racket.
Hackett could really use some people who are excited about the intersection of lisp and haskell and want to build languages to join in on hacking on it :)
I think there are quite a few of those people... maybe that gives some hope for contributions
You are probably underestimating yourself. Imposter syndrome again? Building a language is a major undertaking and I’m sure the help would be appreciated.
I dunno, given https://github.com/lexi-lambda/hackett/issues/98#issuecommen... (saw this when it was sent initially because watching the repo). Knowing one's limits is not necessarily imposter syndrome. If I were to acquire the knowledge (say by reading my recently acquired copy of TAPL), I'll revisit this.
Hackett pushes the boundaries of the Racket macro system, and IIRC through its development has found a number of deficiencies/bugs (I may be misremembering this, however, so don't take it as absolutely true). Besides that, Haskell is a rather complex language, so undertaking the creation of such a thing is no small task. And then we have the issue of
what my own personal knowledge is.
I really hope development once again takes off! Its such a cool project. But I know I wouldn't have the first clue of the right way to do certain things that I know are outstanding.
What are the best library's for data science in Racket?
-Finding it hard to step away from Julia when operate on a amazing large data file and not kill the CPU.
I'm a data engineer and avid Racketeer. Racket is not at all a satisfactory replacement for Julia if you are doing data science. Specifically if you use Flux, you should know deep learning tools are basically non-existent on Racket. Someone once made a paper called DeepRacket and a Github repo, but it hasn't been touched since.
If someone out there knows more than I do please let me know because I'd love to be wrong. There is some decent linear algebra stuff, at least:
https://docs.racket-lang.org/math/matrices.html
Racket is both helped and harmed by it's popularity in certain academic circles. Harmed, in that a lot of graduate students make a thesis of creating some badass library in Racket only to completely abandon it. But I'm still really rooting for Racket, it deserves more hype.
> Racket is both helped and harmed by it's popularity in certain academic circles.
Exactly, in a few ways. One way is that a number of Felleisen's original grad students got professorships and kept doing systems research (and development) with Racket. But most contributors who don't get professorships, nor the handful of researcher jobs, end up working on other systems where the jobs are, academic or industry. Industry use tends to be one-person projects, often because you have a smart person doing something that can't be done with off-the-shelf (e.g., Naughty Dog's video game narrative DSL, a think tank researcher's work, some complicated data science server stuff that I worked on, and various indie moonlighting projects), and so one-person efforts aren't posting jobs. Bigger industry use would mean more contributors, but top programmers are generally ill-equipped for enterprise sales, so I'd bet on startup success stories to jumpstart greater popularity (even if you use Racket to beta, and then whatever you figured out gets rewritten in a popular commodity-worker platform).
For my money, to be an acceptable Python, you have to be able to use the Python numeric, scientific and machine learning libraries -- or have other libraries that are just as good or better. That is the number one reason I would use Python in the first place.
> But I missed parentheses. I longed for parentheses. I dreamed in parentheses
I'm honestly kind of scared to ever learn a Lisp because it seems it permanently alters your brain to the point where it damages your ability to program in other languages (aka ones that you can responsibly use in an organisation can't rely on niche skill sets).
My friend offered to grill me a hamburger last Saturday when we were hanging out in his backyard, but I politely declined. His burgers look desirable, but I explained my concern that tasting one of his burgers might permanently diminish my appreciation of Big Macs. And besides, I can buy a big mac anywhere in the world except north korea, so really that's a more pragmatic preference.
Well I thought I was being diplomatic, but my friend just shook his head and called me a moron. Can you believe the nerve of some people?
(I don't think Lisp damages your ability to program in other languages. But I do think it puts those other languages into context and that context often makes other languages worse than they did before.)
If I were forced to live in Plato's cave, I would rather have no knowledge of anything outside of it.
Many people are locked into an ecosystem by, for example, employment. Why make yourself less happy with the tools you need to use if doing so is for no other benefit? Ignorance can be bliss.
> Why make yourself less happy with the tools you need to use if doing so is for no other benefit? Ignorance can be bliss.
It teaches you how to think about problems in your specific domain more critically, and perhaps more effectively, even if you can't directly translate idioms into another language.
However, would you consider venturing outside the cave if you were allowed to leave the cave every evening? I don't use racket at work, but I enjoy using it on the evenings and weekends. For me programming is both a career and a hobby, and for my hobby stuff, racket is more than viable. I can't have fun with racket during the day, and playing with racket during my freetime might diminish the fun I have at work when using some stodgy language, but for me it's more than worth it.
> Many people are locked into an ecosystem by, for example, employment. Why make yourself less happy with the tools you need to use if doing so is for no other benefit?
Because there is another benefit—what your job required today may not be what it requires tomorrow, and having your head stuck in the sand about everything outside of your current job requirements means your in the worst possible position when that kind of change happens.
I'm quite glad my freshman material was in Racket and not Python. I'm sad to hear some educational programs like MITs are moving the wrong direction here.
I think MIT people had their reasons for "rethinking" and trying out Java, and then Python. One of the factors I recall was a perceived changing nature of CS practice (moving to assembling from components, rather than understanding&building from the ground up), but I can't properly represent all of the rationales here.
Fortunately, the MIT SICP authors made the book freely available, so anyone can continue to work through it, as a complement to our other learning opportunities.
And Racket's `#lang` support is helping to keep the particular Scheme dialect and library used by MIT SICP running on all the currently popular desktops (Unixes, Macs, and Windows): https://pkgs.racket-lang.org/package/sicp
> I think MIT people had their reasons for "rethinking" and trying out Java, and then Python. One of the factors I recall was a perceived changing nature of CS practice (moving to assembling from components, rather than understanding&building from the ground up), but I can't properly represent all of the rationales here.
i really don't fully understand their rationale. as i understand it, just at the time that abelson and sussman grew tired of teaching the course, mit felt the need to restructure their curriculum to meet modern demands and changes in software engineering. of course, things have transitioned from building things up to "poking", but i feel many of the principles of sicp remain unchanged. but even ignoring that, i feel mit made a crucial mistake, in my opinion.
mit is a research and education institute. as a programming language, python is not uniquely suitable for computer science research other than its machine learning and data science library support. i feel it is also not suitable for education either, especially not in the same way a lisp or scheme is. python is what is given to you and thus makes it difficult to explore and implement other paradigms of programming and other ideas in the same language like lisp and scheme can do, and certainly not in the way racket can. now, right next door to mit is northeastern, one of the major racket hubs. racket is a re-envisioned scheme and programming language. it is very much suited to computer science research, building languages for teaching and education (for example, pyret was originally implemented as a racket language), and comes with plenty of library support for general purpose programming. so other than having a lack of libraries for machine learning, data science, and scientific computing, it beats python in every category of comparison. and mit's own language, julia, takes care of those missing components. there's no reason why mit couldn't have developed libraries and teaching packages in racket for their courses.
so imagine if mit had chosen racket as their language. that would bolster racket development and popularity. it could have created a bridge between northeastern and mit and would have taught racket to the thousands of mit students and online students. it could have been a huge leap for racket in terms of popularity and use. and mit could have grown to be an additional hub for racket research and development right next door. and also, racket is an evolution of the scheme language, which would have been a perfect segue from the old curriculum.
but no, mit chose a language that was invented over a period of a couple weeks by a stubborn guy who wanted to replace perl. i strongly suspect that there were political and monetary reasons to choose python. and mit probably has a chip on its shoulder, like it does with everything. mit has also become a university driven by the need to raise money, and i think it has gone all in on taking all the machine learning and "ai" money it can. that later point is probably the real reason.
I agree that SICP is valuable, and years ago, I tried to help make it accessible to people on low-powered computers [1], and to help preserve software support for it [2].
I don't know all the rationale for MIT's moves to other things, but the decision we can see seems plausible to me. (Python is a lingua franca at the moment, popular in ML and data science, still somewhat popular in Web, and very easy to pick up. Even language-nerd me wrote some production Python code that moves large amounts of important data around.)
I agree that modern Scheme (perhaps starting with Racket) seems like a great platform for much of CS-ish education, and for a lot of research and development. I also agree that putting substantial MIT resources behind building out Scheme/Racket seems like it would've been huge. Maybe that will happen.
A lot of MIT behavior emerges from that of individual faculty members and senior research staff, who have some degrees of autonomy. MIT has also prided itself on being big on "experiments", and not having rules that might get in the way of someone exploring ideas. If you have the opportunity, you can try to use that to help make things happen.
One thing that makes Racket somewhat special is that it can be used to build your own languages (e.g. domain specific languages) with it as it comes with the tools and a community that has experience in it.
Probably anyone who would be interested knows it without its needing to be pointed out, but I mention in case it entices anyone that Gregor Kiczales is one of the authors of "The Art of the Meta-Object Protocol" (https://www.amazon.com/Art-Metaobject-Protocol-Gregor-Kiczal... ; edited to remove abbreviation).
Please, what does that mean? I program in Racket, and have enjoyed the vidoes but googling this phrase suggests either Prof Kiczales likes to clean floors in an innovative way, or else he is a member of Hip-Hop group. I'm not finding either terribly credible.
The MOP is the Meta Object Protocol, which is the meta-language for controlling how CLOS operates internally. How exactly are classes, inheritance, instances, slots, method dispatch, method combination, etc implemented? In most object-oriented languages, you have very little insight into these issues and certainly no control over them. In CLOS you have both, thanks to the MOP. Just one more reason why CLOS is the most powerful OO system ever devised.
the course is very, very good. it is based upon the book how to design programs.
as a small correction though, it really doesn't teach racket in terms of #lang racket. it uses a succession of teaching languages that are implemented as #lang languages in racket. however, you do pickup pieces of racket (basically racket used as just a scheme), some of the libraries/frameworks like 2htdp, and DrRacket, the ide.
Racket is often used in academic circles (my University uses it to teach the fundamental CS courses), and also to prototype other programming languages, like a programming-language-language. It has good capabilities for building parsers, grammars, traversing ASTs, and code generation.
Early on, I started doing an incomplete implementation of Arc more like what one of the parent comments suggested, and the working title was "morc: Mock Arc Programming Language as Scheme Extension". I just wanted to learn Arc, while learning Scheme macros better.
Besides possibly adding to the confusion over the relationship between Arc and Racket (or PLT Scheme), my poor choice of title caused at least one community member to be upset, that I would mock (insult) Arc. When I meant only to be self-deprecating of my own exercise, like a poor-imitation or approximation, and not to seem to presume to be implementing a full Arc this way.
Racket is great for some kinds of Web development right now. (Maybe more later, with the development of additional toolkits, and/or maybe a WASM backend after the Chez work.)
I've personally worked on a few industry Web "full-stack" projects in Racket -- including an important large server-heavy system that accomplished something on AWS that no one had yet done before, and a very complex data model HTML5 Offline app (which I did as a mixture of generated and Web services) -- that would not have been possible any other way with the developer resources available. I also used Racket for smaller Web tasks, as a researcher, to whip up a browser-based labeling UI for a large corpus (the corpus was also Web-scraped and massaged by Racket), and to save a big conference demo when the big Java server someone had made could not be deployed on the two-laptop LAN that would be available.
But if a bunch of people hear "Racket is great for Web development" without being more specific, they will run to go look at it, then they will be confused, then they will run at you with pitchforks.
Racket is potentially great for a startup doing a non-cookie-cutter MVP for which they'll have to be clever and invent some things in any case. But Racket is not going to be some variation on some currently-popular framework you already know (maybe it can be backend for one of the frontend frameworks), and you're going to have to write some code to do exactly what you want, not just glue together off-the-shelf components.
I wrote a full feature search engine and web crawler in Racket and it had everything I wanted off the shelf; I was really wowed by how batteries included it was for web development. This was in 2013. It's definitely easier than Node, in my opinion.
When learning to program, Racket was immensely useful to me. The concepts behind Lisp are simple, so I found Lisp to be a good language family to study in order to grasp how programming languages work. These days I prefer Python though.
I've heard of people using it for backend. Moreso than even most lisps, Racket is incredibly powerful. It's really good at building DSLs, since the code is just another data type with the macro system.
Not really sure how this is relevant here, judging by your post history and username you seem to have a one track mind...
Maybe if you provided some examples of how Nim compares to Python or Racket, weighing the pros and cons, etc, I wouldn't assume you're only here to shill Nim.
Edit: Anyone care to explain why my post is flagged and the parent comment isn't? I would like to keep the discussion on topic...I didn't think I was being too harsh.
Your comment broke several of the site guidelines. That's why comments get flagged here. Would you mind reviewing them and sticking to the rules when posting to HN?
What is your complaint? The text seems to expand to fill the browser window. So you set your browser to a comfortable size and then that website is a comfortable size "for free". That, to me, seems like a good thing.
That makes sense when (as in the old days) you have one window per web page, but most people these days have a single window (or a few) with lots of tabs inside that window. You don't want to adapt the window to one particular site when the window is shared for many other sites (for which that site's comfortable size might not be a comfortable size).
It's common practise. It's how web pages commonly work for the last 15 years. Do you prefer Gopher over HTTP/HTML as well? I actually do. This page lives in some in-between universe where all users have their own client side style sheets but still use HTTP/HTML.
For a lot of stuff, Gopher is much better than HTTP/HTML (not for all stuff; and there is also stuff where neither Gopher nor HTTP(S) is good).
I also don't like the webpage stylesheet resizing it and ignoring window size; instead it should just use the window size, and the user should change the font, font size, text width, etc, if they want to do so (also, they should implement split-screen).
I haven't gotten a chance to update the website style since I set it up about 13y ago... it indeed could use a number of css tweaks to be usable on mobile devices, which weren't really available when I set it up.
Your link shows how dang doesn't doesn't like comments complaining about blog layouts. I disagree with dang. Now what? Am I expected to stop using this site because I disagree with the admin? Does this mean I will be banned if I complain?
I don't think it is bikeshedding, and I enjoy judging the writer of the blog for their (according to me) failure to understand the common programmer's aesthetic preference for parenthesis-free code and also failing to understand that people mostly have wide-screen displays and full-width lines don't read very well. Are these musings allowed?
PS I used to have some weird fetish for efficiency before I learnt to value readability.
> Your link shows how dang doesn't doesn't like comments complaining about blog layouts. I disagree with dang. Now what? Am I expected to stop using this site because I disagree with the admin? Does this mean I will be banned if I complain?
I have only looked at the code and built the demos for lambdanative, but from what I have seen if I had to write mobile apps then I would seriously consider it. It is built in the excellent Gambit Scheme.
Lots of "batteries" are included in TXR Lisp: object system with static and instance slots, single inheritance, GC finalization and a form of RAII, exception handling, delimited continuations, byte code compiler for virtual machine, file compilation, macros (of course), regexes, built-in lazy lists, a fantastic set of macros for partial application, a comprehensive declarative FFI, good amount of POSIX wrapage built-in, a decent REPL with history, completion, multi-line editing, visual copy-paste, ...
TXR Lisp has a concept similar to CL's "generalized places" implemented differently. It supports Lisp-1-style evaluation (higher order functions used without a funcall operator), in the middle of a Lisp-2 substrate. Traditional list operations are generalized so they work on other sequences; you can mapcar over a string and such.
Link: https://nongnu.org/txr