（评论）

（评论）
(comments)

原始链接: https://news.ycombinator.com/item?id=40102912

Racket 是用户最喜欢的 Lisp 选择，因为它具有强大的数据包管理系统、带有步骤调试器的图形用户界面 (GUI)、开发跨平台 IDE 的能力、易于生成可运行的二进制文件、友好的社区和全面的学习资源。这些功能使用户能够有效地处理项目并向其他人推荐该语言。他们拥有将其用于各种项目的丰富经验，例如构建和运行电子商务网站、开发本机 macOS 和 iOS 提醒应用程序、为 Apache Kafka 创建跨平台桌面客户端以及为 Lua 构建“lang”。尽管不赞成该语言的某些方面，例如它与学术研究、“Lang”设施和哈佛动态系统项目的联系，但他们承认这些元素是在该语言内开发的独特项目，而不是针对它的批评。总的来说，Racket 因其速度、实用性、坚实的基础和优秀的文档系统而受到重视。

I am happy to see Racket make it to the front page. After using mostly Common Lisp for research programming since 1982, I now more often turn to Racket. There are parts of Racket I don’t like, which is most everything *NOT* the compiler, package management system, GUI IDE, Emacs bindings, fun language to use.

I don’t care for much of the programming language research parts of the ecosystem - that is the parts that the computer scientist professors who run the project probably care about the most. More power to them!

So I feel like a freeloader on the Racket project, just enjoying the little parts I like and ignoring the rest, and not contributing anything (except maybe the little Racket book I wrote).

I agree with every word of this.

The packet management system, the GUI IDE (which includes a step debugger), the ability to write a cross platform IDE (which is maintained by the core Racket team themselves), and the ability to easily produce runnable binaries make Racket my favorite Lisp hands down.

Those features are so incredibly useful and important, I really can't state it enough. I love Lisps, but at work, I will only use a language if it's the best tool for a job. Because of several of those features, Racket has been the only Lisp I've ever been able to justify using.

Because of the community, tooling and learning resources available, Racket is such an easy language for me personally to recommend to people. There are things I really like about CL and Clojure too, both of which I have used quite a bit, but I would never recommend them to people because of some huge drawbacks that come with each.

I also don't jive with the research parts of the language , nor do I care about the "lang" facilities, and I also kind of strongly dislike HtDP. But my perspective on all that is that they are projects I am uninterested in that happened to be made with a language I love, rather than knocks against the language itself, because I never bump up against them.

I use CL on a day to day basis (and not in research/PL research domain), have never ventured into Racked yet. Can you please elaborate further on parts of Racket you don't like vis a vis CL? Thanks!

Not Mark, but I use Racket a lot and sometimes play with Common Lisp.

CLOS is way nicer than Racket's class/OO model and how generic functions are handled. Growable/resizable arrays are sometimes nice to have.

I prefer Racket and Scheme for the most part though.

One reason is that it has one of the best cross platform native gui solutions out there. It exists because the research side was focused on teaching programming and needed a solution that their students could just install. There is a bit of a learning curve, but once you're over the hump it is just a pleasure to work with. See also things like https://docs.racket-lang.org/gui-easy/index.html.

> One reason is that it has one of the best cross platform native gui solutions out there.

I'm always a bit skeptical of these statements. How does it define "native"? Does it use gtk/libadwaita on Gnome and Qt on KDE? What about windows, does it use Win32, WPF, WinUI2 or WinUI3, all of which could be considered "native"? What about platform-dependent layouts?

How one defines "native GUI" is very simple: it uses the native widgets of the desktop OS, rather than custom-painting its own onto a pixel-level canvas. Buttons, input fields, lists/combos, context menus, the file picker dialog, what have you, are from the host system.

This is a wonderful answer!

I return to my main calling: figuring out why people use PLT scheme without an academic incentive. There must be an answer here somewhere....

Ergonomics. It's extremely easy to use, especially in the GUI department. Generally, many things are super easy to use but not always top performance. Other things (macros) are truly exceptionally powerful, but rather complicated.

So, industry-grade customer-facing code? Not its focus, maybe not. But incredibly easy internal tools? Sure!

It becomes very limited quite quickly though. One quickly has to move to the pasteboard editor functionality, where you basically have to recreate everything yourself in a canvas, as the normal buttons and other graphical elements are not supported inside a canvas since they are native OS widgets.

I started trying to build a complex enough GUI and just quit. There are bugs and the documentation is extremely terse. You have to rely on blog posts by one developer who has sorted it all out, but it's still really difficult to get an explicit handle on the concepts and functionality. Very, very few people use the pasteboard editor for complex things or even simple things. You'll be forging a path of your own for sure.

how do you deal with the very bad Racket repl? Thats what turned me off the language

edit: I dont reslly understand the downvotes, not trying to be rude or anything. Coming from CL the racket repl is very very barebones, it loses all state everytime you recompile. So I ask him how he deals with that coming from the very nice CL repl

The REPL in DrRacket is like that because it was made by professors, specifically targeting intro students who had never programmed before. They thought a big Run button with a clean slate each time would be less confusing.

You don't have to use DrRacket to use Racket.

People doing real work with Racket tend to have "workflow" setups that are closer to SLIME.

I personally used a simpler Emacs setup ("https://www.neilvandyke.org/quack/"), and ended up leaning more on modules and embedded unit tests ("https://www.neilvandyke.org/racket/overeasy/"), and less on very dynamic interactive evaluation like I'd done before.

Though, if you want to monkeypatch heavily, CL is famously good at that.

Having used Racket in college for programing language ecosystem, I can say I don't enjoy that aspect either haha. Racket is easy to get started with and definitely great at what it does. If you're wading into Lisp IMO it's the way to go.

That said, IMO Clojure has a larger and more robust community, that said it's a bit of a bigger pain to set up (uses JVM) & has some more nuance.

Uses the JVM is exactly why Clojure is the Lisp like language I mostly bother with.

What matters are ecosystems and not languages on their own, so when switching between languages it is a great benefit that I can reuse my Java ecosystem knowledge, instead of adding yet another ecosystem to those I jump around between projects.

However, I really like the almost Lisp Machine like experience from using Raket.

IMHO, the Lisp Machine experience is completely different. Those have zero educational aspects, they were designed to write large, and stateful, applications, where the Lisp Machine OS is the big stateful object-oriented operating system (like Symbolics Genera). Interlisp-D is even more different.

I like Racket the language a lot, but can't get to terms with the workflow it imposes on you. When coding in Python I use my editor to write the code and I run it from my shell. Doesn't work with Racket because it takes too long to start. Instead you "should" interact with a long-running vm through a REPL. But that means the code you are working on doesn't start with a "clean slate" and instead starts with whatever state the vm is in at the moment. It's a great workflow for things like Jupyter notebooks but doesn't work well for larger programs imo.

> I use my editor to write the code and I run it from my shell

That's a perfectly valid workflow for Racket too. Startup time is pretty comparable to Python in my experience. Slow but not cripplingly so, especially if you compile it ahead of time (useful when you're done working on a file for the moment). Using the racket/base #lang instead of racket makes a big difference too. https://docs.racket-lang.org/style/Language_and_Performance.... has more on that.

>But that means the code you are working on doesn't start with a "clean slate" and instead starts with whatever state the vm is in at the moment.

That sounds more like a Common Lisp style repl than Racket's, where you typically do have to restart Racket when reloading files/modules and thus have a fresh environment. People complain about it but I prefer the clean slate style of Racket over CL.

Welcome to the world of Smalltalk and Lisp Machines, which modern IDEs still don't fully support everything, like hot-reload, saving work states, control over the whole development stack in a single language.

When I studied at the University of British Columbia, racket was taught in the intro to CS course. I thought it was a great language, and put everyone on an even playing field (eg: students with prior programming experience hadn’t worked with lisp). Also was impressed by the libraries which made it easy to produce simple games or visuals.

I also was at UBC for that class and left with a totally different impression. I thought it was awful and set up introductory students very poorly for subsequent CS classes, especially data structures and algorithms that were taught in imperative languages.

When I TAed, a lot of incoming 2nd year students didn’t know how to do for loops yet, which really set them back for basic algorithms.

I had a much deeper appreciation for functional languages after theory of computation classes in my senior / 4th year.

I also TA'd 110 and I firmly disagree. CPSC110 teaches you to view a particular problem as a series of different possible states, and solving for those states (while placing an emphasis on seeing base cases and working up from there). Students learn about data structures like binary trees by the fifth week, and the ninth week they're already able to solve sudoku puzzles using generative recursion. We even touched on the n-queens problem towards the end of the course.

Racket serves its purpose well as a simple and fast to learn educational language; it's easy to see and understand recursion. It's also easy to see what the execution order of statements in your program.

I will say though that some problem sets were a bit brutal in terms of time taken to complete them.

Most data structures taught with imperative languages are just that, data structures for imperative languages, which run on a single CPU core and do not utilize multiple cores well, or at least not without locking mechanisms. One can usually find one of them and copy paste the code, when needed. Much more interesting are purely functional data structures, that can be easily parallelized. That is what universities should teach. I feel like we are quite backward in education with data structures. I can watch a whole data structures lecture/class at no cost besides my own time on YouTube, for famous professors, but when I want to apply it in an FP setting, I will still be dumbfounded and looking for other solutions, which I do not know how to arrive at.

SICP doesn't teach assignment till chapter 3 if I recall correctly, and that was used for years at MIT. I don't think it set CS back there, so maybe it was more a teaching issue?

"When I TAed, a lot of incoming 2nd year students didn’t know how to do for loops yet, which really set them back for basic algorithms."

They hadn't done simple recursive functions over lists? What had they been doing?

Been a while since I had to read introductory material for Racket (or any similar language), but as I recall functions with a base case exit and recursion is usually among the first things they teach.

Racket has a ton of different types of for loops for iterating over data structures etc. and collecting the results (or ignoring them). They're implemented under the hood using recursion but that's hidden from the user and it should be trivial to go from then to other languages. Maybe this class they're talking about didn't cover them?

https://docs.racket-lang.org/guide/for.html

it was indexing and mutating arrays / hashmaps that students had trouble with. Certainly a very different programming model than what’s presented in racket, with recursive iterations.

Of course with years of experience it’s easy to interpolate one from the other but these are students who’ve had 4 months of exposure to programming that have to jump from functional languages into operating systems and data structures and algorithms, all of which are taught with imperative languages

I started with BASIC on C64-/VIC-style machines, then went on to dabble in C, C++, Java, Visual Basic, Delphi Pascal, PHP, before I came into contact with CL and Emacs. Recursion-iteration-equivalence was a mindblower for young me, suddenly I realised more ways to use it for problem solving in the algolians than I had seen before. If I had gone the other way around I'm sure I would have saved a lot of time.

This is surely a single point of anecdata, but it makes me suspect that it was more about how teaching was done than a 'functional vs. imperative' thing. I also suspect pointers and memory management to have been bigger hurdles than how to format code for iteration, unless the Racket course introduced techniques like quoting.

Lisp variants only really have linked lists. So yes you can do recursion over them, but for someone who has never done a C-like language before, the arrays and for loops will take getting used to

No they don't. The basic data structures in Racket are listed here, https://docs.racket-lang.org/reference/data.html . There are also specific array implementations in modules, like the generic array interface in the array module or arrays for math in a math module.

Recursing over a list is a way to learn how to implement for, while and friends. If you know this technique understanding for is just understanding a subset of what you are already familiar with. It can be used to iterate over an arrays as well as lists, e.g. with ranges: https://docs.racket-lang.org/reference/pairs.html#%28def._%2...

Racket can also be used to teach object oriented programming and programming with structs, if the aim is to teach patterns used in C-like languages generally it's not a bad fit. Well, except advanced stuff like pointer witchery. Though you could probably implement a teaching language that does it with arrays or the byte code directly if you wanted to. It might be a good way to improve on error messages for pedagogical purposes.

I'm lost on how should I integrate all these "languages" of Racket into a single application. Like, I can see there are `typed/racket`, `racket/gui` and `scribble/base` languages. But how do I write a GUI application that create PDF while also having all the code be typed? I tried following Racket tutorial multiple times but I'm still lost on how to tied each unrelated "languages" together.

IMO, each chapter of the tutorial just talk about unrelated "language" and then never once show how they all work together. One chapter will talk about web server but not class system, then another chapter will talk about another "language" that support class but then never write web server in it.

You can think of the #lang line as a kind of compiler instruction with that file as scope. There's much more to it but that's a good starting point. If you have an application and want to add types doing it one file at a time is a good strategy.

Besides the #lang line you can also use 'require to bring in libraries, so a single file could contain GUI as well as web server code. #lang isn't constrained to one language at a time either, if they don't conflict you can just add more to that line.

This is a very personal conflict between prominent community members. The larger racket community is very friendly, including the core team.

Felleisen is an insufferable prick but also easy to avoid. More a symptom of an illness in academia than Racket specifically, I'd say. In the community there are some 'weird nerds' with strong opinions that are likely to be more annoying since their presence is more strongly felt, but that's just how it is in many social settings where money doesn't chain things down.

Racket is my favorite language. It's fast, practical, has solid foundations and an extremely nice concurrency story (based on concepts borrowed and extended from Concurrent ML). It has an excellent documentation system, with an integrated package ecosystem, which means that most packages have high quality documentation with cross-references. It has a great backwards-compatibility story -- a lot better than Python's, for example, which I use in my current dayjob. So, my impression of the commenters saying it's too academic or not practical is that they probably never dove deeply enough, or they are former students who were only exposed to the teaching languages in the past. It's definitely not perfect: the community is small, the runtime has a high memory baseline, parallelism requires spinning up a Racket VM per system thread, among others, but these are things that will improve over time.

In the past several years, I've:

* built & run an e-commerce site written in Racket[1]

* built a native macOS and iOS reminders app, available on the App Store [2, 3, 4]

* built a cross-platform desktop client for Apache Kafka [5, 6, 7]

* built a `#lang` for Lua [8]

Among[9] other[10] things[11]. I think that's all pretty practical stuff!

[1]: https://defn.io/2019/08/20/racket-ecommerce/

[2]: https://defn.io/2020/01/02/ann-remember/

[3]: https://defn.io/2024/04/09/ann-remember-for-ios/

[4]: https://github.com/bogdanp/remember

[5]: https://defn.io/2022/11/20/ann-franz/

[6]: https://defn.io/2023/10/15/ann-franz-for-windows/

[7]: https://defn.io/2023/08/10/ann-franz-source-available/

[8]: https://defn.io/2022/11/12/ann-racket-lua/

[9]: https://docs.racket-lang.org/http-easy/index.html

[10]: https://docs.racket-lang.org/deta/index.html

[11]: https://docs.racket-lang.org/gui-easy/index.html

~20 years ago I worked on commercial software for email security that was using MzScheme (before it became PLT Scheme) as the base language. Code was cross-platform (Solaris, Linux, HP-UX) - OS-specific code was in C, with about 1k lines. Filter rules were compiled into Scheme itself. The whole code was about 30k LoC, including web based UI, and only had 5-6 developers… Later I immigrated and joined company that had similar product with less features with code in C++, with hundred thousand LoC and more developers.

Racket is a very practical language. If you have the impression that it's some academic quirk you should take a look at what Bogdan Popa is doing with it: https://defn.io/

When I personally want a binary with a native GUI I turn to Racket. It's also pretty nice for parsing stuff, like JSON, XML, some text-file formats.

The companion book How to design programs, https://htdp.org/2023-8-14/Book/index.html , is nice too, while it doesn't exactly teach Racket (it uses a couple of teaching languages implemented in Racket) it has some valuable ideas that are good to be reminded of every now and then.

The macro system might seem weird if one comes from e.g. CL, but once I got used to it I found it relatively easy to stay sane while doing metaprogramming.

A couple of more resources that are useful:

https://www.greghendershott.com/fear-of-macros/

https://beautifulracket.com/

I feel like when I dive into LISPs like Racket or SBCL I’m presented with a very academic purist view of programming that clashes with my desire for more tangible, material apps. I feel like I’d be able to comprehend deep computer science theorems in CL well but god forbid if I wanted to crank out a weekend web app.

Racket is very academic, but Common Lisp (SBCL is an implementation of the CL standard) is not really academic in my opinion its mostly an industrial language. It is an incredibly practical language and its exactly what I reach to to crank a weekend webapp. Its fast and unopinionated and the repl is a godsend for the quick iteration required to do a weekend hack. I think it may just look like that from the outside due to preconceived notions of what lisps are.

CL mostly allows you to do whatever you want, at its core it is a compiled, imperative, garbage collected language, with incredible interaction and introspection capabilities and the ability to modify the language in a very straightforward way (take code, modify code). It just has a weird syntax to be able to do macros and reason about macros

Most of the books and tutorials about Racket are by academics. So people who start with those will get that impression.

But if you dig in to hacking with Racket (or another Scheme!) as a powerful general-purpose language, and to some extent ignore the "pedagogy" stuff, there's a lot of serious programmer stuff.

The CL books I've seen, OTOH, tend to be pretty practical, but also more technical than your average Python/JS just-get-me-a-job books.

A big thing to know about Lisps is that they're nigh-unemployable (other than Clojure, if you want to work in an enterprise Java shop)... so Lisps disproportionately attract the kind of people who would be programming computers even if it weren't a well-paying job.

My point of view is that if you want to use CL in your shop, you better have serious money as the people that can do it without blowing everything up are the same people that can find a good job somewhere else. Lisp is more like spell-crafting than house-building (Forth is like that too), so after a while, the system is more like a new language entirely. You have to get a team of highly disciplined engineers and it's not something the current state of the industry tend to do.

LISP to Python (and therefore a job) is really just moving the left hand parenthesis after the function name, replacing spaces with commas, discarding everything good and right about homoiconicity, and embracing a nigh sickening amount of syntactic sugar around OOP.

Give me a decent LISP programmer who is willing to compromise and I can get you a job.

Macro is the name of the game and where you go from programming the business rules using a language to directly stating the rules themselves.

Something like (def-action name ..) and it generates the whole routing handling, response generating code for you in a web application. Kinda like, but more powerful than the decorators you find in Flask.

Unfortunately it also means throwing away compiled code, in JIT and AOT form.

Still looking forward to the day Python ecosystem fully embraces it, without going through using C and calling it Python, or reaching to implementations that are 80% there and are largely ignored by the community.

Thankfully the whole AI stuff is putting pressure into making JITs part of the standard Python workflow and I am looking forward to that Python 3.13 release.

Let me propose to you an idea that bridges a Lisp and a weekend web app for you: write the infamous TODO app using the React framework using a Lisp. Transpile that Lisp into JavaScript to get it to run in a browser. Depending on your level of perseverance either write that transpiler yourself, or pick one that already exists (like ClojureScript), or even just write your function that outputs JS.

I have done that a decade ago before React was even popular. Even if only the syntax is different, it was and is much nicer than writing JSX.

I use racket and sbcl both. I prefer sbcl. We write a lot of software in cl; it is excellent. Cannot say anything else beats the debugging experience unless really low level, but for embedded we use c code gen from cl anyway.

Yeah, different use-case really. Personally I enjoy the more “academic” languages, like the LISPs and Haskell. I play around with them for things like Advent of Code and small POCs, but _rarely_ anything approaching a useful/production-ready application.

I like Racket because of these things

1. Package manager

2. Cross platform Gui

3. Easy to install on all platforms

4. Gradually typed language Typed-Racket that checks types at compile time

5.fast (has moved from middle of the pack to top 3 fastest Schemes)

6. Evolution under the hood as opposed to just syntax and features (chez scheme over C)

7. Simple IDE with Emacs built in which makes getting started if you are afraid of Emacs easier.

8. Documentation languages like Pollen and Scribble make writing documentation better than any other language I have used

9. Zuo, a Make replacement which works like a mini Racket

10. Large active community

11. Modern communication channels (Discord, Discourse Forum, subreddit)

12. Documentation geared towards beginners or experienced programmers (Racket Guide vs Racket Reference)

13. You can turn a Racket program into an executable (it’s far but better than Python’s options that’s for sure)

There are Schemes that I like better for specific things (Gambit-C for C integration, Gerbil as a Racket Successor, Chez as the Fastest Scheme, Guile for its large GNU ecosystem)

But no Scheme has come close to offering even half of what you get with Racket out of the box

I also like Racket for a good few of these reasons, but the tooling has a lot of sharp edges and limitations in practice. It would be unfair to expect a full JetBrains/Microsoft IDE experience but it surprised me that a Lisp descendant would come with such an underpowered default REPL. I also find, whatever the technical merits of Scribble compared to docstrings and Markdown, that the documentation for most Racket packages is poorly written compared to that for even minor packages in common languages.

What do you think it is missing for Racket to be more widespread in the industry? Do you think being a lisp is the biggest factor or something else?

In my opinion, the reason it and other languages aren't more popular is that they don't have a "halo" product that forces you to use it.

For example look at Elisp. It might be the most successful lisp in the modern Era because of Emacs. Emacs alone is like over a million lines of Elisp, and the ecosystem of packages is gigantic. A lot of people do not like Elisp, and there have been many attempts to create Emacs + a better language (Guilemacs, First/Second Climacs). But it has all failed because Emacs proper has a lot of momentum, and you can't build Emacs + a better language. You need Emacs + a better language + a better/bigger ecosystem... Because while lots of people use ELisp in Emacs, more people are just calling use-package on what ever package someone else created.

Take another example, JavaScript. You want to write a dynamic web application, you use JavaScript. There is no shortage of tweets of JavaScript trivia where the person shows JavaScript adding two non nonsensical objects together and getting an even more nonsensical answer. If you don't program in JavaScript (or even if you do) you look on in horror and go "Why would anyone use this awful language!". Then you go use your electron based desktop apps, and run millions of lines of JavaScript in the browser. Are there better languages for the web than JavaScript? Sure lots of languages clear that low bar. But is there any language with a comparable ecosystem that also works as seamlessly in the domains that JavaScript works in? I'd argue no. JavaScript has so much momentum that it even spills over into areas where it shouldn't be used (I.E the desktop and the backend) but it can go anywhere at this point (including custom ARM CPU instructions https://developer.arm.com/documentation/dui0801/h/A64-Floati...)

I'd say the same thing about Python as I did about JavaScript (I am a Python dev). If the official OpenAI Api had been written in Racket there would be millions of Racket users right now and a bunch of new and awesome package, but it's written in Python.

Another example is Zig. I actually think that Zig has a chance to compete in the programming language. I started using Zig not because of any particular feature of the syntax, or the libraries it had, but simply because trying to compile cross platform C/C++ applications using a combination of GCC, LLVM, MSVC, and building for Arm, X86_64, etc is so awful, that using Zig instead is a better solution. This will be the gateway for most people to Zig IMO, and then from there the ecosystem will follow.

There is one edge case and that is Swift. I actually think Swift is a good language, and has a lot going for it. It definitely has the chops to be a good low level compiled language with good C/C++ integration. But a lot of its popularity is due to Apple having the power to make it the de facto language on iOS, just like Google can with Kotlin. But that will only help on the platforms they own (which are admittedly a lot more than most languages), but to gain the viral cross platform adoption, it will require an actual effort on Apple's part to make that happen, along with some dedicated fans of the language. Right now, using Swift without Xcode is hard, even with the VsCode plugin. I know Miguel de Icaza is at least one of those hardcore Swift fans, and is trying to get the Swift Godot project up. That could be the gateway to Swift for people outside of the Apple ecosystem but we will see.

In professional settings the right people are usually the hardest to come by, and the most expensive part of the business. Recruiting is very resource intensive, some of your most expensive employees spend a lot of time figuring out ways to lure candidates in, discarding applications, running interviews and so on.

In software development it can take up to a year until someone has turned out to not be a good fit, because the systems are quite large and the first few months will in most cases be spent introducing the basics of them. That's a rather hefty investment for most companies, except the very large ones.

So as a manager, why would you bet on Racket? Unless you understand the peculiarities and power in macros (and eager to teach it over and over again) you won't, because the board will roast you over bringing in the risk that you can't find replacements when core developers inevitably move on.

If there was something unique you could only use if you had Racket developers it would pull in broader industry usage, but as far as I know no such thing exists.

As a single or few developer consulting business/dev boutique things change, you'd only have to convince customers and they like shiny things that solve their problems or make money, and if you and your comrades know Racket well you could very well create such shiny problem-solvers relatively fast. Then you'd only have to resist the attraction of better pay and someone else closing the sales once the business is up and running.

I think we really need to separate the two aspects of CS education. Universities should not be job training centers and vice versa. We already have bootcamps, etc. which provide very practical training. I'm pretty sure that CS is the only field with complaints about not being practical enough. Mathematics, physics, medicine, etc. all manage to get along fine.

Being “job ready” (whatever that means) is a side-effect and a byproduct of a university education, not the end. The telos is to teach you how to learn and think well. In this regard Racket is almost as good as you can get. (I’d personally rank the Shplait language (new; implemented in Racket/Rhombus) as best for teaching.)

Anyone who learns Racket will have learned ways of deconstructing problems that will make them far superior in problem solving to those who learn only e.g. Java and only know how to do things the OO™ way.

I will say that the credential was a big part of why I studied CS in my 30s. I learned a number of languages along the way.

At this point, nearly all the code I write is in JScript, Pl/SQL, Python, and T-SQL. I learned none of these while in school: Javascript was not yet invented when I was getting the degree.

I will say that SNOBOL, of all odd languages, was useful to me after school in learning Perl.

（评论） (comments)

（评论）
(comments)