--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20191002192745.F408C650189%40mail-svr1.cs.utah.edu.
Hi all,
I had written a few of my early thoughts about ‘racket2’, but after mulling over all this for a good year, I’d like to write something more definitive.
My background: I started programming in BASIC on C64, followed by ADA, Pascal, C and macro-assembly on 8086 with MASM in the 90’s. My main hobby as a teen was to make demos in assembly, trying to squeeze every byte out of 64kb’s. Once my ‘low-level honeymoon’ phase faded, I went on a quest to find a high level language which would make me more productive and spare me the pain of having to explain every little detail directly to the CPU.
Through work I have had to write a lot of JavaScript and PHP for the Web, plenty of C++, later replaced by C# for Windows-only projects. I played with Go for network services, toyed with Nim for automation, and later (painfully) learned Rust just to see if it was a viable Assembly substitute. I found Rust way more annoying to learn and use than Assembly. For me, Macro-Assembly + Win32 API is still the combo to beat to produce tiny, fast internal apps with no dependencies other than the OS. Over the years, my MASM macro library has grown so much that I can write an entire GUI app, in a language that looks like BASIC. Only it compiles to a few kilobytes, loads instantly and runs on any version of Windows since 95. If only I could do that in a cross-platform way... so for anything client-facing, x-platform on the desktop, I ended up joining the masses, and use C++/Qt.
During my quest for the ultimate language, I played with Common Lisp, Haskell and OCaml, but only found true love with Scheme, which I found ‘purer’ and closer to my idea of a universal, ‘100-years language’. Racket only amplified my attraction to parentheses and multi-paradigm languages. I now use Racket every day to write internal automation tools, and have developed over 100 command-line and GUI apps to do anything from file format conversion to video encoding/decoding, to financial analysis, to production asset tracking and packaging. Some of these tools span dozens of modules.
To the point: what would make Racket2 the ultimate tool (for me):
I am well aware that what I’m wishing for isn’t necessarily compatible with Racket’s intended public’s needs (comp-sci teachers and students? That’s the impression I’m getting). But Racket is the most advanced general purpose programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to academic use?
Racket’s home page starts with ‘Racket - Solve Problems - Make Languages’. That very first line will scare anybody looking to just... write programs. Yes it is the entire point, but why not try and go back to basics with Racket2, and (also) tackle what really matters? Easily writing correct, fast and powerful programs that let us build tomorrow’s technologies.
Dex
On Apr 28, 2020, at 5:23 PM, David Storrs <david....@gmail.com> wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAE8gKof%3DcqMfVE-meV0R3WNX7mp20zVKm02eYOcM-rUAgiCZzg%40mail.gmail.com.
At Wed, 29 Apr 2020 11:14:47 +0200, Dexter Lagan wrote:
> To the point: what would make Racket2 the ultimate tool (for me):
> Performance. Faster startup times, shorter execution times in general.
> Optionally, a ‘lite’ version of Racket that compiles directly to no-deps
> binaries, bypassing the JIT altogether, would be a game-changer. As far as
> high levels languages with functional concepts and metaprogramming facilities
> that compiles to tiny, fast bins, Nim comes dangerously close, but it’s not a
> Lisp, and it’s not Racket.
> Production-quality, modern and fast GUI facilities. I’ll take properly
> documented, complete Qt bindings. Racket/GUI is great for internal tools, but
> it quickly becomes slow, tedious and limited for more complex client-facing
> UIs.
> One complete, commercial-grade Web framework, inspired from Symphony or
> Laravel. Security and ease of use first, continuations later.
> Better documentation: Racket docs are aesthetically very pleasing, complete
> and detailed. However some parts are still very obscure and lacking simple
> examples (if only the part about Continuations included just one basic
> example, such as a ‘return’ implementation, on the very first page. If only
> the Macros documentation started with define-simple-macro and a few very
> basic, practical examples. Instead we’re greeted with pattern-based macros,
> which although very powerful, are very hard to comprehend for newcomers).
Which of these things will you be working on?
> I am well aware that what I’m wishing for isn’t necessarily compatible with
> Racket’s intended public’s needs (comp-sci teachers and students? That’s the
> impression I’m getting). But Racket is the most advanced general purpose
> programming tool I’ve ever seen. Wouldn’t it be a shame if it was limited to
> academic use?
https://www.youtube.com/watch?v=LN0qG-i1iT0&feature=youtu.be
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5ea97134.1c69fb81.8c167.2c68SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
Greetings,I would be interested as well.Thanks,Jeff
On Apr 29, 2020, at 8:27 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote:
Hi David,
If you ping me on Slack, I'll be happy to walk you through how to make
changes to the docs. And maybe you can lend a hand to finally
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
They say that Racket is slow. I would like to know who are "they".
Racket can be surprising. For example - our GUI application on RPi has a
start-up time of 24s... But when we compile it using `raco exe`, it goes
down under 2s including some hardware setup the program does. Usually
the slow startup times are caused by not using compiled byte-code.
As I have mentioned a few times on this list, I am working on a side
project right now which pushes Racket to its limits and let's say that
the results might look impossible to many people. Full 3D rendering
pipeline in pure Racket with no external libraries (no OpenGL, no SDL,
just pure Racket) which can run at 60fps FullHD kind of beats the
argument "Racket is slow".
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/7d816c28-21a7-85d0-355d-b32030d60354%40trustica.cz.
They say that Racket is slow. I would like to know who are "they".
My experience is quite contrary to that. In the last three years we were
forced to develop a few GUI tools used by our customers and there are no
complains only against the tools using racket/gui. Yes, it is far from
perfect - but it is the only thing that really behaves consistently
across all three platforms we need to support (Linux, Mac, and ...
Windows). Python+Qt and go+Qt are absolutely insupportable without a
long list of per-platform/per-widget hacks. It might be that we are just
hitting corner cases (actually that's pretty probably), yet with Racket
there were no such hurdles.
> * One complete, commercial-grade Web framework, inspired from Symphony
> or Laravel. Security and ease of use first, continuations later.
And this is the part that made me actually hit the "Reply List" button.
The good thing about mentioned PHP frameworks is only that anyone can
start producing something with them without any prior experience. So
right now we are encountering vulnerable and unmaintainable code
anywhere we bump into some 3rd party "web application" we are hired to
audit. With Racket - the entry barrier is really high, I agree. I
actually spent many days getting through it - but once you pass the
barrier, it really helps you write applications where you can focus on
the actual functionality and let the libraries do the rest for you. And
securing such application is almost trivial task. Yes, I have hit some
corner cases here as well, but if you follow for example Bogdan's
work[2][3], you'll see that there are solutions readily available. It is
just necessary to read the docs and understand how the whole thing works.
I am not sure whether it is the best thing to start with
define-simple-macro (if anything, I'd start with define-syntax-rule),
but yes, more examples are always useful. Just write them and send a
pull request to appropriate repository - I was pleasantly surprised when
I first did this. All the Racketeers are super helpful when it comes to
incorporating any improvements. (Thanks Ben!)
As far as I can tell, it is definitely limited to academic use. Although
I prepare support materials for my students with Racket, I actually
teach Clojure - so for me, Racket is tool mostly for my business and
only remotely for my academic activities. But I guess that I am a corner
case here :)
You would be surprised, why so many people in the industry use Perl.
They use it for producing what is effectively a pile of DSLs. And they
are really keen on trying to do the same with Racket once they find out
they can. I really think that it the perception that making languages is
something hard is biased. If you go to a carpenters workshop, you
probably won't understand much of what they say, even though you are
talking the same language. Then if you would come to visit aerospace
engineers and hear them talking about their latest improvements to
whatever they are doing, again, it will be a different dialect. And in
my opinion, this is exactly what Racket provides us with - common
platform (Racket, English, UTF-8, math ...) and you can create a dialect
that suits your needs. Quickly and without sacrificing any
inter-operational possibilities.
And - as it is evident - I don't need project Rhombus for my work. I am
really happy with Racket as it is. I do not even use brackets...
everything is just plain parentheses to me. Yet I am really closely
following the project to see what it will bring. Because although I use
parentheses exclusively, I use at-exp for certain use-cases and it
boosts my productivity tenfold at least. But on my own, I would never
think about something like at-exp syntax. So I don't know what will
project Rhombus bring and I am pretty sure that right now it is
something I cannot help with, but I can definitely say I like the
approach the core team is taking to research the possibilities.
(Not directly related to Rhombus) Speaking of “how to contribute”, I find that it is not friendly at all to setup stuff in order to contribute to Racket core and main distribution. According to https://blog.racket-lang.org/2017/09/tutorial-contributing-to-racket.html, if I want to make a change to, say, https://github.com/racket/math, I should start with:
$ raco pkg update --no-setup --catalog https://pkgs.racket-lang.org math
$ raco pkg update --clone math
The estimated time to run the above two commands is ONE HOUR! The second command in particular seems to compile every Racket packages (why does it need to do that?!?) which takes a lot of time.
I really feel turned off by the thought of having to wait for one hour (with my laptop becoming very hot from CPU usage at 100%, and I can’t really do other work that has heavy computation during this period). So I usually skip this step, but that also means I can’t test my PR locally. Instead, I need to rely on CI to catch any mistake that I made. The obvious drawback is that it generates a lot of noises to people watching the repo and some repos don’t even have CI setup…
(In some cases, I can test locally by isolating the changes to a new Racket program, but that’s not always possible.)
Is it possible to improve this somehow?
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/5ea9f62b.1c69fb81.d0413.1033SMTPIN_ADDED_MISSING%40gmr-mx.google.com.
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAK%3DHD%2BZ5k%2BFk2guk8sxe8gs-kQ9NcKJLkHGeWprrucFzqZ%2BABA%40mail.gmail.com.