Thanks so much for your reply, it's very nice to see another perspective. I
added specific comments below :

They say that Racket is slow. I would like to know who are "they".
>

  Same here, never had a problem, but I do understand there may be
requirements for real-time apps and system programming. Everything I said
about performance really should be put into the context of wider
acceptance. I don't look at benchmarks, but all of my colleagues do, and
that deeply saddens me. Being a better tool isn't necessarily just being a
faster tool, but performance attracts people and businesses.

  If there was two things I'd love to look at, performance-wise - and they
aren't related to Racket itself - it would be the 2-3s lock-up I get after
opening DrRacket. I can type a line of code, and everything locks up for a
few seconds before I can type again. It's nothing big, but it's so annoying
that I'm considering downloading the source tree and hack at it. The other
problem I'm encountering is the relatively slow scrolling / navigation,
again in DrRacket. I usually disable all the plugins, and sometimes even
debugging to get smoother performance. But Racket itself isn't slow at all.
Considering the power it provides, it's very fast.


> 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.
>

  True, Racket's gui seems to cross over much better than most frameworks.
I use MrEd to make more complex GUIs, and so far the main limitation that
prevents me from using it for production (beyond tiny UIs for internal
tools) is the relatively limited listbox (I haven't figured out how to edit
cells or color text. But that's probably because I haven't dug the docs
enough, and I stopped looking when I read other people's similar complains
(for ex https://news.ycombinator.com/item?id=18048347)


>
> >   * 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 couldn't get myself to go through the Web app tutorials. I ended up
writing a framework in NewLisp mainly made out of macros spitting out
Boostrap chunks.
https://github.com/dexterlagan/newstrap
I ran out of time when I hit multi-page navigation. That's when I
understood why everybody uses WP or Symphony. Time is money, and most
people who make a living out of Web apps/sites just don't have the time to
learn a new language. I asked some of the Web developers in my team to go
through the Racket Web tutorials, and all of them loved the power, but went
straight back to WordPress, where they feel at home surrounded by thousands
of plugins they can simply install and invoice to our clients. All of this
really annoys me, and I stay away from the Web side of things, just because
I can't stand the idea of making something, only to have to write it again
in two years using a different framework, in a different language. I think
that until there's a real commercial interest in making a competitive
framework in Racket, people will not use the language for the commercial
Web. Maybe it's better this way?


> 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!)
>

I didn't know it was that easy. I don't use version control beyond Fossil's
basic functions, so I'll have to read up on all this. I'd love to
contribute to documentation.


> 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 :)
>

  Same here, apart from myself, I don't know anybody else who uses Racket
for production. I'm the Lisp/Racket evangelist in my department, and I
can't imagine using anything else for automation and exploratory
programming. It has replaced every other language in my toolset, apart from
C++/Qt, for the reasons mentioned previously.

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.
>

  Racket's language oriented programming idea always fascinated me, but I
could never wrap my head around it. I use macros a lot, but an entire
language? It's hard enough to have decent naming conventions, I can't
imagine what it would be, having to explain to other programmers how my DSL
works just so they can contribute to my code base. I try to stick to very
strict style standards, and try hard to keep my code pure and
dependency-free, and I still step on my toes when I go a little bit too
crazy on macros. I will never understand how they mix languages in the
Racket codebase. A higher form of intelligence is probably required :)


> 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.
>

Same here, parens all the way, I don't use brackets. I'm very excited by
the possibility of having a non-s-expr syntax that keeps Racket's
language-oriented superpowers.

Cheers,

Dex

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/racket-users/CACUENr%2BfkMmFf8crZ%2BA89t7qBtGA-T8QgnYbrtuDFMi26rT-QQ%40mail.gmail.com.

Reply via email to