Re: [racket-users] Intro and projects inquiry

[Jack Firth]

>
> > Racket doesn't play well with existing code bases (except C things) 
> > and so my hypothesis is simply that to gain adoption of Racket, you 
> > need to solve problems that aren't in the "production path." Good 
> > thing there are *lots* of those! All those Python scripts you have? 
> > All of those Perl scripts that no one understands anymore? Those are, 
> > in my opinion, the way in. 
>
> Funny story: That's how I cam back to Racket/Scheme. Several years ago I 
> worked on a web application written in Common Lisp. I needed some 
> "electronic duct tape" work done. I didn't use Common Lisp because of 
> its slow startup time and I was unhappy with shell scripts either. 
> Therefore I remembered that there was PLT Scheme/Racket around with 
> "batteries included". So nowadays lot of these tasks are now done using 
> Racket. 
>

There are some really neat packages that help make writing these sorts of 
scripts in Racket
easier. The Rash  language is designed 
with a line-based syntax and pipelining features similar
to traditional shell scripting languages, but because it's a Racket lang 
you can import Racket
libraries for use in your script and you can extract parts of your shell 
script into regular Racket
modules as the script grows in complexity.

There's also the Scripty  language, 
which does something a bit weird: it lets you write what
packages a script depends on inside the script itself, and when the script 
is run it will automatically
check to see if they're installed and prompt the script user to install 
them if they're not. This lets
you use whatever packages you like in your Racket scripts without burdening 
your coworkers with
the task of making sure those packages are installed and up to date before 
trying to run the script.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Daniel Brunner]

Am 13.10.2017 um 00:20 schrieb Andrew Gwozdziewycz:
> Racket doesn't play well with existing code bases (except C things)
> and so my hypothesis is simply that to gain adoption of Racket, you
> need to solve problems that aren't in the "production path." Good
> thing there are *lots* of those! All those Python scripts you have?
> All of those Perl scripts that no one understands anymore? Those are,
> in my opinion, the way in.

Funny story: That's how I cam back to Racket/Scheme. Several years ago I
worked on a web application written in Common Lisp. I needed some
"electronic duct tape" work done. I didn't use Common Lisp because of
its slow startup time and I was unhappy with shell scripts either.
Therefore I remembered that there was PLT Scheme/Racket around with
"batteries included". So nowadays lot of these tasks are now done using
Racket.

Daniel


-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Eric Griffis]

On Thu, Oct 12, 2017 at 2:27 PM Andrew Gwozdziewycz 
wrote:

> I love seeing all of these project ideas, but I really don't think
> Racket needs a "killer app." I think what it needs is the people
> passionate about it building tools in it, and *using* those tools in
> the work place, and sharing the experiences of using those tools more
> vocally.
>

This line of reasoning also works in reverse. When Racket becomes more
popular, people will talk about it more. There's a network effect to
consider.


> We need people building tools and blogging about why using Racket made
> the job easier. Why would it be harder to do in Python, or Ruby? We
> need straight up advocacy, and that starts with everyone in this
> thread who *hasn't* done that yet.
>

These activities are good for hardcore developer advocacy. They are less
effective at swaying casual devs who can't code themselves out of a jam.

You might get some push back on [...]. Explain to them [...]
>

Education is important. It's also slow and expensive. In my experience,
"lead by example" is a more effective starting strategy than "show them the
light."

Anyway. I don't think it makes sense to solve problems that you don't
> have.


I've made a career out of solving other people's problems. It's why I'm an
expert tool maker and an awful astrophysicist. Programmers and
astrophysicists need each other to remain relevant.

Ideas are cheap, but it's an easy way to get people taking. And this kind
of discussion can lead to truly valuable insights as we share interests,
hopes, pain points, and coping mechanisms.

Eric

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Hendrik Boom]

On Thu, Oct 12, 2017 at 09:07:48AM +1100, Daniel Prager wrote:
> Great topic!
> 
> Providing examples and tutorials around data analysis and visualisation in
> Racket (and filling gaps and simplifying) gets my vote.

The biggest problem wth almost all free software is documentation.
Sometimes it's simply absent; sometimes it's there but inadequaate, 
obsolete, or wrong; sometimes it's just impossible to find.  Even a 
Google search gets lost in a plethora of helpful hints posted 
randomly about the web so you won't find the authoritative stuff even 
when it exists.

-- hendrik

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

['Royall Spence' via Racket Users]

In this case, I'm thinking of the unfortunate JVM error messages from
Clojure. As far as I know, the main reason to suffer through Clojure's
attachment to the JVM is that no other Lisp has the same level of
support for web applications.

The second reason may be something about performance, but we can
probably close that gap with some different approaches. I'm specifically
thinking of taking a shot at a libev-based server like Common Lisp's Woo
for higher performance, although that would be a shot in the dark
because I don't understand the details affecting server performance
right now.

On Fri, Oct 13, 2017, at 11:55 AM, James wrote:
> 
> On Oct 13, 2017, at 9:44 AM, 'Royall Spence' via Racket Users wrote:
> 
> > Since we're bikeshedding here, I think we'd benefit from having a web
> > toolkit on par with Clojure's Luminus. We only need a few more packages,
> > a website documenting their interoperation, and a project skeleton to
> > create the same sort of experience with the benefit of better error
> > messages. I've already built one of the easy pieces (dotenv), and I'm
> > working on more more of them. Some of the things I'd like to include,
> > like server diagnostics, are a little over my head at the moment. I
> > intend to keep checking off the boxes, though, and have a
> > production-ready "framework" available sometime.
> 
> That's really good.  It's a pet peeve of mine that web sites and web
> tools often don't give, bury or suppress error messages.  My guess is
> that it started with the notion that you should suppress error messages
> to make SQL injection attacks harder.  I don't agree with that idea in
> the first place, much less in other areas besides opportunities for code
> injection.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[James]

On Oct 13, 2017, at 9:44 AM, 'Royall Spence' via Racket Users wrote:

> Since we're bikeshedding here, I think we'd benefit from having a web
> toolkit on par with Clojure's Luminus. We only need a few more packages,
> a website documenting their interoperation, and a project skeleton to
> create the same sort of experience with the benefit of better error
> messages. I've already built one of the easy pieces (dotenv), and I'm
> working on more more of them. Some of the things I'd like to include,
> like server diagnostics, are a little over my head at the moment. I
> intend to keep checking off the boxes, though, and have a
> production-ready "framework" available sometime.

That's really good.  It's a pet peeve of mine that web sites and web tools 
often don't give, bury or suppress error messages.  My guess is that it started 
with the notion that you should suppress error messages to make SQL injection 
attacks harder.  I don't agree with that idea in the first place, much less in 
other areas besides opportunities for code injection.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

['Royall Spence' via Racket Users]

In my experience, it means two seemingly opposite things that unify to
create bad software. On the one hand, it's an extreme conservatism and
fear of attempting new things. Don't try a new language, just keep using
PHP. Don't install the new PHP version with better features, it could be
risky. Don't use automated library management and deployment, we don't
understand it. Don't use git, it sounds scary.

On the other hand, this same attitude of underconfidence and low
ambition drives the adoption of dubious tooling. We cannot possibly be
smart enough to write our own application, so use this slow and
confusing web framework. Google and Facebook use these heavy Javascript
tools, so we'd better do that, too, on every single project. Who are we
to defy the "experts" in our field?

At least, that's been my experience in 10 years of web development. It's
perfectly fine to make mistakes, but I can't stomach the repetition.
Enough of my complaining, though.

Since we're bikeshedding here, I think we'd benefit from having a web
toolkit on par with Clojure's Luminus. We only need a few more packages,
a website documenting their interoperation, and a project skeleton to
create the same sort of experience with the benefit of better error
messages. I've already built one of the easy pieces (dotenv), and I'm
working on more more of them. Some of the things I'd like to include,
like server diagnostics, are a little over my head at the moment. I
intend to keep checking off the boxes, though, and have a
production-ready "framework" available sometime.

On Fri, Oct 13, 2017, at 08:25 AM, David Storrs wrote:
> On Fri, Oct 13, 2017 at 2:27 AM, Eric Griffis  wrote:
> > On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:
> >>
> 
> > Web dev culture is a bigger issue.
> >
> > Eric
> 
> How so?
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Matthias Felleisen]

So someone should organize a loosely connected group to port the core of Racket 
to the JVM: 
  — racket
  — the macro system 
  — all non-GUI libraries 
and provide a Clojure-style way to leverage the GUI libraries. 

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[David Storrs]

On Fri, Oct 13, 2017 at 2:27 AM, Eric Griffis  wrote:
> On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:
>>

> Web dev culture is a bigger issue.
>
> Eric

How so?

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Eric Griffis]

On Thu, Oct 12, 2017 at 9:31 AM David Storrs  wrote:

> My suggestion would be that the single largest thing that would make
> Racket take off is if it could become a replacement for Javascript.


RacketScript Playground does not optimize tail calls. If it turned ES6
strict mode on, and if strict mode works as advertised, could RacketScript
leverage more Racket code to some advantage?

It's an interesting problem, but I doubt making Racket work better in the
browser would have the desired effect. Web dev culture is a bigger issue.

Eric

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[James]

I think a prominent cross platform GUI application which demonstrates the 
quality of interface you can get with relatively little effort in Racket would 
go a long way.  I find JAVA GUI s to be painful.  There is also a Python cross 
platform GUI but, judging by PgAdmin 4, I'm not impressed.  

A related idea would be Racket for rapid development of database clients.  This 
could be especially good if some easy database connection elements were added 
to MrEd Designer.  This is a crowded field but it's such a common need that a 
better tool would be welcome.  

James

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Andrew Gwozdziewycz]

On Thu, Oct 12, 2017 at 10:02 PM, David Storrs  wrote:
> On Thu, Oct 12, 2017 at 5:27 PM, Andrew Gwozdziewycz  wrote:
>> We need people building tools and blogging about why using Racket made
> I agree that talking about how great Racket is will be an important
> part of increasing uptake.  That said, I contend that it is not
> enough.  People have been talking about how awesome LISP is for
> literally decades, and many of those people are influencers.  Example:
>  Paul Graham, who is essentially the god of Silicon Valley startups,
> has blogged extensively about how amazing LISP is and how it vastly
> increased the speed of his startup.  Despite that, I know of exactly
> zero SV startups that are using LISP -- I've been out of the valley
> for a couple years now, so maybe it's changed, but I was there for
> quite a while and never heard of any.

To be fair, despite Mr. Graham's talk, he didn't exactly put a lot of
code out that *showed* anyone anything. But take Clojure as an
example. It's got an advantage in that there's an immediate avenue for
getting it integrated with an existing codebase -- It's written in
Java. Adopting it to try it out isn't a big thing if you're already a
JVM shop.

But what if you *aren't* a JVM shop? Why would you adopt Clojure? It's
really not because of the libraries, or frameworks around it. Most of
that, at least early on, was really surface level stuff, except for
maybe Ring for web apps. But, Ring really isn't all that special...
either. Still, Clojure was successful *outside* of the world of the
JVM. ClojureScript maybe even more so!

Racket doesn't play well with existing code bases (except C things)
and so my hypothesis is simply that to gain adoption of Racket, you
need to solve problems that aren't in the "production path." Good
thing there are *lots* of those! All those Python scripts you have?
All of those Perl scripts that no one understands anymore? Those are,
in my opinion, the way in.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[David Storrs]

On Thu, Oct 12, 2017 at 5:27 PM, Andrew Gwozdziewycz  wrote:
> I love seeing all of these project ideas, but I really don't think
> Racket needs a "killer app." I think what it needs is the people
> passionate about it building tools in it, and *using* those tools in
> the work place, and sharing the experiences of using those tools more
> vocally.
>
> We need people building tools and blogging about why using Racket made
> the job easier. Why would it be harder to do in Python, or Ruby? We
> need straight up advocacy, and that starts with everyone in this
> thread who *hasn't* done that yet.
>
> I started the thread about a "graphviz" like because I'd like to write
> documentation without pointing and clicking--including the figures I
> need to illustrate a point. That's not a killer app, but that's
> something that I can *share* inside the work place to make the lives
> of developers (who'd rather declare a drawing, than fight to point and
> click with it), to have an integrated documentation system they can
> use from their editor. It makes sense to me, and I'm sure it'd make
> sense to them, too.
>
> You might get some push back on the parentheses! You might get some
> push back on the fact that Racket has it's roots in "LISP"
> (intentionally capped). But, that's an opportunity. Show your
> coworkers the *why*. Explain to them why it's powerful. Explain to
> them that they can set up an editor to do parentheses matching.
> Explain to them contracts, or Typed Racket, or how powerful the
> language extension model is.
>
> Anyway. I don't think it makes sense to solve problems that you don't
> have. Solve your own problems, but do it in Racket. Then spread the
> word that Racket made it easy, fun, and elegant! Be sure to somehow
> include that the community is extremely welcoming, helpful, and
> growing!

I agree that talking about how great Racket is will be an important
part of increasing uptake.  That said, I contend that it is not
enough.  People have been talking about how awesome LISP is for
literally decades, and many of those people are influencers.  Example:
 Paul Graham, who is essentially the god of Silicon Valley startups,
has blogged extensively about how amazing LISP is and how it vastly
increased the speed of his startup.  Despite that, I know of exactly
zero SV startups that are using LISP -- I've been out of the valley
for a couple years now, so maybe it's changed, but I was there for
quite a while and never heard of any.

So, yes.  Talking Racket up is necessary, but it's not enough.
There's a chicken and egg problem -- there's no one in the private
sector who lists Racket on their resume, so there's no jobs to be had
in Racket.  There's no jobs to be had in Racket, so there's no reason
to learn Racket for your resume.  Everyone is constantly busy and
staying on the SOTA curve in order to maintain employability is
difficult.  If I'm a working programmer I have N hours of study time
in a week.  There are lots of interesting things to study, so would I
devote those precious hours to Racket (something that doesn't make me
more employable and which no one I know is using) as opposed to
learning a more popular tool (e.g. a web framework, or a job-viable
programming language) or a popular field of study (e.g. machine
learning, data science) that opens up entire new career tracks for me?

The key rule of sales is "find the pain, fix it".  Simply saying "use
Racket because it's awesome" does not fix anyone's pain; they are
perfectly happy with the languages they're using, so there is no pain
there.  On the other hand, show them a tool that solves a problem they
have (a source of pain) and they will happily learn this weird,
unemployable, thing-I-never-heard-of language in order to use it.



>
> On Thu, Oct 12, 2017 at 9:09 PM, James  wrote:
>>
>>> Does a killer app or library sorely need a Racket alternative?
>>
>> Let me throw out a few things which we would use in our business even if 
>> they are not the most pressing needs in general.  We have ways to work 
>> around these things but It would be much nicer to have a Racket native 
>> solution.  I have numbered the list but they are really in no particular 
>> order.
>>
>> 1. Libsodium - We need to do some sophisticated encryption and web of trust 
>> stuff.  See earlier comments on this list by Tony Garnock-Jones.
>>
>> 2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
>> working on using FFI to either PJNATH or libnice.  A pure Racket 
>> implementation would be great.  It should probably be combined with Tony G's 
>> efforts on UPnP and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal. 
>>  This is an area which has suffered greatly from a lack of the right people 
>> coming together and agreeing on a good standard.  ICE is a method for 
>> prioritizing and selecting from multiple competing standards which may each 
>> be the best choice in different 

Re: [racket-users] Intro and projects inquiry

[Andrew Gwozdziewycz]

I love seeing all of these project ideas, but I really don't think
Racket needs a "killer app." I think what it needs is the people
passionate about it building tools in it, and *using* those tools in
the work place, and sharing the experiences of using those tools more
vocally.

We need people building tools and blogging about why using Racket made
the job easier. Why would it be harder to do in Python, or Ruby? We
need straight up advocacy, and that starts with everyone in this
thread who *hasn't* done that yet.

I started the thread about a "graphviz" like because I'd like to write
documentation without pointing and clicking--including the figures I
need to illustrate a point. That's not a killer app, but that's
something that I can *share* inside the work place to make the lives
of developers (who'd rather declare a drawing, than fight to point and
click with it), to have an integrated documentation system they can
use from their editor. It makes sense to me, and I'm sure it'd make
sense to them, too.

You might get some push back on the parentheses! You might get some
push back on the fact that Racket has it's roots in "LISP"
(intentionally capped). But, that's an opportunity. Show your
coworkers the *why*. Explain to them why it's powerful. Explain to
them that they can set up an editor to do parentheses matching.
Explain to them contracts, or Typed Racket, or how powerful the
language extension model is.

Anyway. I don't think it makes sense to solve problems that you don't
have. Solve your own problems, but do it in Racket. Then spread the
word that Racket made it easy, fun, and elegant! Be sure to somehow
include that the community is extremely welcoming, helpful, and
growing!

On Thu, Oct 12, 2017 at 9:09 PM, James  wrote:
>
>> Does a killer app or library sorely need a Racket alternative?
>
> Let me throw out a few things which we would use in our business even if they 
> are not the most pressing needs in general.  We have ways to work around 
> these things but It would be much nicer to have a Racket native solution.  I 
> have numbered the list but they are really in no particular order.
>
> 1. Libsodium - We need to do some sophisticated encryption and web of trust 
> stuff.  See earlier comments on this list by Tony Garnock-Jones.
>
> 2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
> working on using FFI to either PJNATH or libnice.  A pure Racket 
> implementation would be great.  It should probably be combined with Tony G's 
> efforts on UPnP and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal.  
> This is an area which has suffered greatly from a lack of the right people 
> coming together and agreeing on a good standard.  ICE is a method for 
> prioritizing and selecting from multiple competing standards which may each 
> be the best choice in different circumstances.  UPnP and NAT-PMP are only 
> partial solutions for us and we really need STUN and TURN as well.
>
> 3. Advanced fountain codes - For example, https://arxiv.org/abs/1605.09125.  
> I haven't seen a Racket native library for basic Reed-Solomon erasure codes 
> either.
>
> 4. A DSL alternative to GraphViz - see my other message.
>
> 5. #lang R or some other method to combine Racket and R - We need to go to R 
> for computational work because that's what is trusted in the field.
>
> James
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.



-- 
http://www.apgwoz.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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Philip McGrath]

On Thu, Oct 12, 2017 at 4:09 PM, James  wrote:
>
> 5. #lang R or some other method to combine Racket and R - We need to go to
> R for computational work because that's what is trusted in the field.


I published a package called opencpu (
http://docs.racket-lang.org/opencpu/index.html) that provides a little bit
of abstraction on the Racket side over the OpenCPU HTTP API for R (
https://www.opencpu.org/). I haven't used it in production (because I
persuaded my colleagues in the project for which I wrote it to just
implement the functionality in pure Racket), but it may be a useful
starting point for others. I welcome suggestions, forks, and pull requests!
https://github.com/liberalartist/opencpu

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[James]

> Does a killer app or library sorely need a Racket alternative?

Let me throw out a few things which we would use in our business even if they 
are not the most pressing needs in general.  We have ways to work around these 
things but It would be much nicer to have a Racket native solution.  I have 
numbered the list but they are really in no particular order.  

1. Libsodium - We need to do some sophisticated encryption and web of trust 
stuff.  See earlier comments on this list by Tony Garnock-Jones.

2. ICE NAT traversal - We need to do this and do it well.  Currently we are 
working on using FFI to either PJNATH or libnice.  A pure Racket implementation 
would be great.  It should probably be combined with Tony G's efforts on UPnP 
and NAT-PMP,  https://github.com/tonyg/racket-nat-traversal.  This is an area 
which has suffered greatly from a lack of the right people coming together and 
agreeing on a good standard.  ICE is a method for prioritizing and selecting 
from multiple competing standards which may each be the best choice in 
different circumstances.  UPnP and NAT-PMP are only partial solutions for us 
and we really need STUN and TURN as well.

3. Advanced fountain codes - For example, https://arxiv.org/abs/1605.09125.  I 
haven't seen a Racket native library for basic Reed-Solomon erasure codes 
either.

4. A DSL alternative to GraphViz - see my other message.

5. #lang R or some other method to combine Racket and R - We need to go to R 
for computational work because that's what is trusted in the field.  

James

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[James]

> I enjoyed following the graph drawing thread a few weeks ago. A serious 
> attempt at "better than graphviz" could be fun and worthwhile.

I was going to reply to that thread as well but didn't get to it.  There is a 
great need for something like this in bioinformatics.  Down the road a bit, we 
will want something like it for the startup business which I am in.  We are 
developing bioinformatics software and one of the things on our to do list is a 
module for graphing protein-protein interactions.

Have a look at this paper:
http://bit.ly/2yfXTip

I painstakingly created figure 1C in Cytoscape.  I was unable to make similar 
graphs, much less the more sophisticated ones I would like to create, for 
subsequent publications because it just took too much time.  Of course I wanted 
to automate the process.  I tried scripting Cytoscape but found that to be too 
tedious and unreliable.  I looked into creating a Cytoscape plugin but it was 
too much work and I would have had to learn Java.  Most of my programming 
experience, so far, has been Perl and R.  I researched a bunch of different 
options and then turned to a GraphViz library for R but found that it was too 
limited.  Finally, I wrote some custom R code to create GraphViz code.  This 
got me the farthest but I would really like to have something nicer than 
GraphViz to work with.

Figure 1C is combining raw gene expression profiling data with Gene Set 
Enrichment Analysis (GSEA) to indicate the activity of various transcription 
factors.  The raw data and GSEA scores are then graphed in the context of the 
most significant transcription factors and their known target genes.  This can 
be a very powerful way of looking at the data under the right circumstances.  
The more common situation is looking at a combination of expression profiling 
data with mutation calls from sequencing in the context of known 
protein-protein interactions.  There are some commercial options which do some 
of this but they are not very good and not really open enough to allow for 
accessible and reproducible research.  Our model is to charge for participation 
in our network and for what will eventually become our platform software.  The 
analytical tools and community contributed analytical modules will be open 
source so you can see exactly what they are doing.  

Moving forward, something which has been an idea for a long time but not yet 
done satisfactorily, as far as I know, is to show proteins as either logic 
gates or analog circuits.  Proteins are viewed, in many cases, as forming 
signal networks.  It would be good to be able to show an animation of how the 
signal flow over the network changes with different environmental signals.  
Alternatively, hold the environmental signals constant and show what happens to 
the signal flow if you add/remove a mutation in one of the proteins.  So that's 
a step or two beyond what GraphViz does but I think it's a logical direction to 
go for further development.  

James

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Matthias Felleisen]

David’s reference is to Vishesh’s RacketScript. Please see (seventh RacketCon). 
Contributions welcome. 




> On Oct 12, 2017, at 1:00 PM, 'Royall Spence' via Racket Users 
>  wrote:
> 
> Unfortunately, Whalesong's current fork requires an old version of Racket and 
> hasn't seen a commit to master in several months. Racketscript is under 
> active development, though, and provides a mostly-complete implementation of 
> Racket for Javascript. Seems comparable to Clojurescript in its vision.
> 
> https://github.com/vishesh/racketscript
> 
> 
> On Thu, Oct 12, 2017, at 12:43 PM, Thomas Lynch wrote:
>> Apparently Whalesong is such an alterntiave. 
>> https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
>>A Lisp dialect, Clojure, has caused a lot of young folks to ask 
>> questions/to think about Lisp 
>> (https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e).
>> 
>> On Thu, Oct 12, 2017 at 4:31 PM, David Storrs  wrote:
>> My suggestion would be that the single largest thing that would make
>> Racket take off is if it could become a replacement for Javascript.
>> The browser is the default GUI for most work these days, and doing
>> real-time interfaces in the browser requires Javascript.  If Racket
>> could run inside the browser and was more convenient to work with than
>> Javascript then it would start climbing the hockey stick.  That would
>> be an enormous project and I don't even know how you would get the
>> popular browsers to adopt it; forking the browsers won't work and nor
>> will making a plugin / addon -- it's got to run out of the box so that
>> developers can rely on the fact that visitors to their site will be
>> able to use it.
>> 
>> For now, something that made it trivial to compile Racket to
>> Javascript is probably the best option.  As it happens, I believe
>> there is some effort in that direction. :>
>> 
>> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke  wrote:
>> > Eric Griffis wrote on 10/11/2017 07:44 PM:
>> >>
>> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke > >> > wrote:
>> >>
>> >>
>> >> * Being there soon with a Web Assembly and HTML5 plus server
>> >> full-stack
>> >> story, in case developers respond favorably to that.
>> >>
>> >>
>> >> Web back-ends are my wheelhouse. It sure would make my professional life
>> >> easier... Not gonna lie, this isn't something I'd look forward to banging
>> >> out alone.
>> >
>> >
>> > There are some scalable HTTP protocol handling things I'd like to try,
>> > including some hardcore systems-ish programming, and then multiple parties
>> > (including me) could layer independent framework-y things over that
>> > (server-side-only, and client-side-too).
>> >
>> > The WebAssembly part is what might be an emerging opportunity, but am
>> > guessing the best way involves working with the tentative new Chez backend
>> > for Racket.  (Also, WebAssembly didn't look very simple nor yet as
>> > well-documented as you'd want, and looks still being hammered out.  So,
>> > knowing how adopted Web standards tend to happen... you might have to put 
>> > in
>> > considerable effort to catch up with and track it, buy a gorilla suit, 
>> > munch
>> > some beetle grubs[1], and hopefully become accepted by the pack, to be
>> > confident that Racket will be a first-class citizen in WebAssembly.)
>> >
>> >> * Push DSL-based programming, for which Racket might already have the
>> >> best technology.  (The other day, I saw someone looking to hire
>> >> developers to use some DSL-based speculative methodology thing...
>> >> in Ruby.)
>> >>
>> >>
>> >> This might also be interesting. Any concrete demand out there to drive the
>> >> process?
>> >
>> >
>> > Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
>> > methodologists are always clamoring to invent and brand approaches, now
>> > including applications of DSLs. :)
>> >
>> > (DSLs can be little mini-languages used by programmers as part of any kind
>> > of programming, they can be used by programmers mix traditional language
>> > paradigms in a code base, they can be used to support domain
>> > experts/specialists capturing and maintaining knowledge/behavior separate
>> > from programmers.)
>> >
>> >>
>> >> The Godot game engine is kinda like this, but for Python. It has a lot of
>> >> rough edges, which could help design a good Racket alternative. There may 
>> >> be
>> >> a ton of reusable functionality in a project like that.
>> >
>> >
>> > Over a decade ago, someone was actually doing game engine-ish stuff using
>> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
>> > simulator for first-responders in emergency scenarios.  It might've used 
>> > the
>> > open-sourced Quake engine, or just built atop OpenGL; I forget whether I
>> > heard.  At the time, I guess 

Re: [racket-users] Intro and projects inquiry

['Royall Spence' via Racket Users]

Unfortunately, Whalesong's current fork requires an old version of
Racket and hasn't seen a commit to master in several months.
Racketscript is under active development, though, and provides a mostly-
complete implementation of Racket for Javascript. Seems comparable to
Clojurescript in its vision.
https://github.com/vishesh/racketscript


On Thu, Oct 12, 2017, at 12:43 PM, Thomas Lynch wrote:
> Apparently Whalesong is such an alterntiave.
> https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
> A Lisp dialect, Clojure, has caused a lot of young folks to ask
> questions/to think about Lisp
> (https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e)
> .> 
> On Thu, Oct 12, 2017 at 4:31 PM, David Storrs
>  wrote:>> My suggestion would be that the single 
> largest thing that would make>> Racket take off is if it could become a 
> replacement for Javascript.
>> The browser is the default GUI for most work these days, and doing
>> real-time interfaces in the browser requires Javascript.  If Racket
>> could run inside the browser and was more convenient to work
>> with than>> Javascript then it would start climbing the hockey stick.  That 
>> would>> be an enormous project and I don't even know how you would get the
>> popular browsers to adopt it; forking the browsers won't work and nor>> will 
>> making a plugin / addon -- it's got to run out of the box
>> so that>> developers can rely on the fact that visitors to their site will be
>> able to use it.
>> 
>> For now, something that made it trivial to compile Racket to
>> Javascript is probably the best option.  As it happens, I believe
>> there is some effort in that direction. :>
>> 
>> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke
>>  wrote:>> > Eric Griffis wrote on 10/11/2017 07:44 PM:
>> >>
>> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke
>> >> > >> > wrote:
>> >>
>> >>
>> >> * Being there soon with a Web Assembly and HTML5 plus server
>> >> full-stack
>> >> story, in case developers respond favorably to that.
>> >>
>> >>
>> >> Web back-ends are my wheelhouse. It sure would make my
>> >> professional life>> >> easier... Not gonna lie, this isn't something I'd 
>> >> look forward to
>> >> banging>> >> out alone.
>> >
>> >
>> > There are some scalable HTTP protocol handling things I'd like
>> > to try,>> > including some hardcore systems-ish programming, and then 
>> > multiple
>> > parties>> > (including me) could layer independent framework-y things over 
>> > that>> > (server-side-only, and client-side-too).
>> >
>> > The WebAssembly part is what might be an emerging opportunity,
>> > but am>> > guessing the best way involves working with the tentative new 
>> > Chez
>> > backend>> > for Racket.  (Also, WebAssembly didn't look very simple nor 
>> > yet as>> > well-documented as you'd want, and looks still being hammered
>> > out.  So,>> > knowing how adopted Web standards tend to happen... you 
>> > might have
>> > to put in>> > considerable effort to catch up with and track it, buy a 
>> > gorilla
>> > suit, munch>> > some beetle grubs[1], and hopefully become accepted by the 
>> > pack,
>> > to be>> > confident that Racket will be a first-class citizen in
>> > WebAssembly.)>> >
>> >> * Push DSL-based programming, for which Racket might already
>> >>   have the>> >> best technology.  (The other day, I saw someone 
>> >> looking to
>> >> hire>> >> developers to use some DSL-based speculative methodology
>> >> thing...>> >> in Ruby.)
>> >>
>> >>
>> >> This might also be interesting. Any concrete demand out there to
>> >> drive the>> >> process?
>> >
>> >
>> > Chattering about DSLs now seems mainstream.  Also, Agile-esque
>> > upstart>> > methodologists are always clamoring to invent and brand
>> > approaches, now>> > including applications of DSLs. :)
>> >
>> > (DSLs can be little mini-languages used by programmers as part of
>> > any kind>> > of programming, they can be used by programmers mix 
>> > traditional
>> > language>> > paradigms in a code base, they can be used to support domain
>> > experts/specialists capturing and maintaining knowledge/behavior
>> > separate>> > from programmers.)
>> >
>> >>
>> >> The Godot game engine is kinda like this, but for Python. It has a
>> >> lot of>> >> rough edges, which could help design a good Racket 
>> >> alternative.
>> >> There may be>> >> a ton of reusable functionality in a project like that.
>> >
>> >
>> > Over a decade ago, someone was actually doing game engine-ish stuff
>> > using>> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D
>> > training>> > simulator for first-responders in emergency scenarios.  It 
>> > might've
>> > used the>> > open-sourced Quake engine, or just built atop OpenGL; I forget
>> > whether I>> > heard.  At the time, I guess a Lisp was a big enough win for 
>> > that,
>> > and 

Re: [racket-users] Intro and projects inquiry

[Thomas Lynch]

Apparently Whalesong is such an alterntiave.
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js
A Lisp dialect, Clojure, has caused a lot of young folks to ask
questions/to think about Lisp (
https://m.oursky.com/why-i-chose-clojure-over-javascript-24f045daab7e).

On Thu, Oct 12, 2017 at 4:31 PM, David Storrs 
wrote:

> My suggestion would be that the single largest thing that would make
> Racket take off is if it could become a replacement for Javascript.
> The browser is the default GUI for most work these days, and doing
> real-time interfaces in the browser requires Javascript.  If Racket
> could run inside the browser and was more convenient to work with than
> Javascript then it would start climbing the hockey stick.  That would
> be an enormous project and I don't even know how you would get the
> popular browsers to adopt it; forking the browsers won't work and nor
> will making a plugin / addon -- it's got to run out of the box so that
> developers can rely on the fact that visitors to their site will be
> able to use it.
>
> For now, something that made it trivial to compile Racket to
> Javascript is probably the best option.  As it happens, I believe
> there is some effort in that direction. :>
>
> On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke 
> wrote:
> > Eric Griffis wrote on 10/11/2017 07:44 PM:
> >>
> >> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke  >> > wrote:
> >>
> >>
> >> * Being there soon with a Web Assembly and HTML5 plus server
> >> full-stack
> >> story, in case developers respond favorably to that.
> >>
> >>
> >> Web back-ends are my wheelhouse. It sure would make my professional life
> >> easier... Not gonna lie, this isn't something I'd look forward to
> banging
> >> out alone.
> >
> >
> > There are some scalable HTTP protocol handling things I'd like to try,
> > including some hardcore systems-ish programming, and then multiple
> parties
> > (including me) could layer independent framework-y things over that
> > (server-side-only, and client-side-too).
> >
> > The WebAssembly part is what might be an emerging opportunity, but am
> > guessing the best way involves working with the tentative new Chez
> backend
> > for Racket.  (Also, WebAssembly didn't look very simple nor yet as
> > well-documented as you'd want, and looks still being hammered out.  So,
> > knowing how adopted Web standards tend to happen... you might have to
> put in
> > considerable effort to catch up with and track it, buy a gorilla suit,
> munch
> > some beetle grubs[1], and hopefully become accepted by the pack, to be
> > confident that Racket will be a first-class citizen in WebAssembly.)
> >
> >> * Push DSL-based programming, for which Racket might already have
> the
> >> best technology.  (The other day, I saw someone looking to hire
> >> developers to use some DSL-based speculative methodology thing...
> >> in Ruby.)
> >>
> >>
> >> This might also be interesting. Any concrete demand out there to drive
> the
> >> process?
> >
> >
> > Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
> > methodologists are always clamoring to invent and brand approaches, now
> > including applications of DSLs. :)
> >
> > (DSLs can be little mini-languages used by programmers as part of any
> kind
> > of programming, they can be used by programmers mix traditional language
> > paradigms in a code base, they can be used to support domain
> > experts/specialists capturing and maintaining knowledge/behavior separate
> > from programmers.)
> >
> >>
> >> The Godot game engine is kinda like this, but for Python. It has a lot
> of
> >> rough edges, which could help design a good Racket alternative. There
> may be
> >> a ton of reusable functionality in a project like that.
> >
> >
> > Over a decade ago, someone was actually doing game engine-ish stuff using
> > PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
> > simulator for first-responders in emergency scenarios.  It might've used
> the
> > open-sourced Quake engine, or just built atop OpenGL; I forget whether I
> > heard.  At the time, I guess a Lisp was a big enough win for that, and
> there
> > were a lot fewer and more primitive 3D game engines, that it made sense.
> > Today, whenever there is again a win to using Racket, I'd probably end up
> > taking an off-the-shelf (preferably libre-licensed) 3D game engine that
> met
> > all the other requirements, and make it work well with Racket.
> >
> > [1] Gary Larson, The Far Side, "So you're a *real* gorilla, are you?
> ...".
> > https://i.pinimg.com/736x/da/ed/ed/daeded47decfd2a200aca58b00a9d0e5.jpg
> >
> >
> > --
> > 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 

Re: [racket-users] Intro and projects inquiry

[David Storrs]

My suggestion would be that the single largest thing that would make
Racket take off is if it could become a replacement for Javascript.
The browser is the default GUI for most work these days, and doing
real-time interfaces in the browser requires Javascript.  If Racket
could run inside the browser and was more convenient to work with than
Javascript then it would start climbing the hockey stick.  That would
be an enormous project and I don't even know how you would get the
popular browsers to adopt it; forking the browsers won't work and nor
will making a plugin / addon -- it's got to run out of the box so that
developers can rely on the fact that visitors to their site will be
able to use it.

For now, something that made it trivial to compile Racket to
Javascript is probably the best option.  As it happens, I believe
there is some effort in that direction. :>

On Wed, Oct 11, 2017 at 10:37 PM, Neil Van Dyke  wrote:
> Eric Griffis wrote on 10/11/2017 07:44 PM:
>>
>> On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke > > wrote:
>>
>>
>> * Being there soon with a Web Assembly and HTML5 plus server
>> full-stack
>> story, in case developers respond favorably to that.
>>
>>
>> Web back-ends are my wheelhouse. It sure would make my professional life
>> easier... Not gonna lie, this isn't something I'd look forward to banging
>> out alone.
>
>
> There are some scalable HTTP protocol handling things I'd like to try,
> including some hardcore systems-ish programming, and then multiple parties
> (including me) could layer independent framework-y things over that
> (server-side-only, and client-side-too).
>
> The WebAssembly part is what might be an emerging opportunity, but am
> guessing the best way involves working with the tentative new Chez backend
> for Racket.  (Also, WebAssembly didn't look very simple nor yet as
> well-documented as you'd want, and looks still being hammered out.  So,
> knowing how adopted Web standards tend to happen... you might have to put in
> considerable effort to catch up with and track it, buy a gorilla suit, munch
> some beetle grubs[1], and hopefully become accepted by the pack, to be
> confident that Racket will be a first-class citizen in WebAssembly.)
>
>> * Push DSL-based programming, for which Racket might already have the
>> best technology.  (The other day, I saw someone looking to hire
>> developers to use some DSL-based speculative methodology thing...
>> in Ruby.)
>>
>>
>> This might also be interesting. Any concrete demand out there to drive the
>> process?
>
>
> Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart
> methodologists are always clamoring to invent and brand approaches, now
> including applications of DSLs. :)
>
> (DSLs can be little mini-languages used by programmers as part of any kind
> of programming, they can be used by programmers mix traditional language
> paradigms in a code base, they can be used to support domain
> experts/specialists capturing and maintaining knowledge/behavior separate
> from programmers.)
>
>>
>> The Godot game engine is kinda like this, but for Python. It has a lot of
>> rough edges, which could help design a good Racket alternative. There may be
>> a ton of reusable functionality in a project like that.
>
>
> Over a decade ago, someone was actually doing game engine-ish stuff using
> PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D training
> simulator for first-responders in emergency scenarios.  It might've used the
> open-sourced Quake engine, or just built atop OpenGL; I forget whether I
> heard.  At the time, I guess a Lisp was a big enough win for that, and there
> were a lot fewer and more primitive 3D game engines, that it made sense.
> Today, whenever there is again a win to using Racket, I'd probably end up
> taking an off-the-shelf (preferably libre-licensed) 3D game engine that met
> all the other requirements, and make it work well with Racket.
>
> [1] Gary Larson, The Far Side, "So you're a *real* gorilla, are you? ...".
> https://i.pinimg.com/736x/da/ed/ed/daeded47decfd2a200aca58b00a9d0e5.jpg
>
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Neil Van Dyke]

Eric Griffis wrote on 10/11/2017 07:44 PM:
On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke > wrote:



* Being there soon with a Web Assembly and HTML5 plus server
full-stack
story, in case developers respond favorably to that.


Web back-ends are my wheelhouse. It sure would make my professional 
life easier... Not gonna lie, this isn't something I'd look forward to 
banging out alone.


There are some scalable HTTP protocol handling things I'd like to try, 
including some hardcore systems-ish programming, and then multiple 
parties (including me) could layer independent framework-y things over 
that (server-side-only, and client-side-too).


The WebAssembly part is what might be an emerging opportunity, but am 
guessing the best way involves working with the tentative new Chez 
backend for Racket.  (Also, WebAssembly didn't look very simple nor yet 
as well-documented as you'd want, and looks still being hammered out.  
So, knowing how adopted Web standards tend to happen... you might have 
to put in considerable effort to catch up with and track it, buy a 
gorilla suit, munch some beetle grubs[1], and hopefully become accepted 
by the pack, to be confident that Racket will be a first-class citizen 
in WebAssembly.)



* Push DSL-based programming, for which Racket might already have the
best technology.  (The other day, I saw someone looking to hire
developers to use some DSL-based speculative methodology thing...
in Ruby.)


This might also be interesting. Any concrete demand out there to drive 
the process?


Chattering about DSLs now seems mainstream.  Also, Agile-esque upstart 
methodologists are always clamoring to invent and brand approaches, now 
including applications of DSLs. :)


(DSLs can be little mini-languages used by programmers as part of any 
kind of programming, they can be used by programmers mix traditional 
language paradigms in a code base, they can be used to support domain 
experts/specialists capturing and maintaining knowledge/behavior 
separate from programmers.)




The Godot game engine is kinda like this, but for Python. It has a lot 
of rough edges, which could help design a good Racket alternative. 
There may be a ton of reusable functionality in a project like that.


Over a decade ago, someone was actually doing game engine-ish stuff 
using PLT Scheme (earlier version of Racket), to, IIRC, develop a 3D 
training simulator for first-responders in emergency scenarios.  It 
might've used the open-sourced Quake engine, or just built atop OpenGL; 
I forget whether I heard.  At the time, I guess a Lisp was a big enough 
win for that, and there were a lot fewer and more primitive 3D game 
engines, that it made sense.  Today, whenever there is again a win to 
using Racket, I'd probably end up taking an off-the-shelf (preferably 
libre-licensed) 3D game engine that met all the other requirements, and 
make it work well with Racket.


[1] Gary Larson, The Far Side, "So you're a *real* gorilla, are you? 
...". 
https://i.pinimg.com/736x/da/ed/ed/daeded47decfd2a200aca58b00a9d0e5.jpg


--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Jack Firth]

>
> Web back-ends are my wheelhouse. It sure would make my professional life 
> easier... Not gonna lie, this isn't something I'd look forward to banging 
> out alone.
>

I've been looking into web stuff for Racket quite a bit, specifically web 
microservices. Shoot me an email if you're interested in more details.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Eric Griffis]

On Wed, Oct 11, 2017 at 2:58 PM Neil Van Dyke  wrote:

>
> * Being there soon with a Web Assembly and HTML5 plus server full-stack
> story, in case developers respond favorably to that.
>

Web back-ends are my wheelhouse. It sure would make my professional life
easier... Not gonna lie, this isn't something I'd look forward to banging
out alone.


> * Push DSL-based programming, for which Racket might already have the
> best technology.  (The other day, I saw someone looking to hire
> developers to use some DSL-based speculative methodology thing... in Ruby.)
>

This might also be interesting. Any concrete demand out there to drive the
process?

* Find other application or technology niches that people want right
> now, and figure out some value-added support for them other than SaaS
> bindings that everyone else is doing.  Deep learning and other machine
> learning, traditional scientific/stats programming and visualization,
> voice AI-ish assistants, FPS video game engines, GPU targeting, etc.
>

The Godot game engine is kinda like this, but for Python. It has a lot of
rough edges, which could help design a good Racket alternative. There may
be a ton of reusable functionality in a project like that.

Thanks, Neil!

Eric

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Daniel Prager]

Great topic!

Providing examples and tutorials around data analysis and visualisation in
Racket (and filling gaps and simplifying) gets my vote.

Another area that might be interesting is generating data-driven web-sites:
e.g. presenting questionnaires and quizzes.

I recently did a bit of consulting  work where I used:

   1. Racket to do some data preparation
   2. Google Forms to run a questionnaire based on the data (SurveyMonkey
   would have been an alternative)
   3. Racket to do some collation and data crunching on the answers
   4. Google Sheets to do some simple visualisation  (mainly for the heat
   mapping feature)
   5. gmail to assemble reports and post the results

It would have been very nice to replace some of the semi-manual non-Racket
steps with all-Racket or Racket-scripted (taking to external APIs).

Dan

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Neil Van Dyke]

Welcome, Eric.

That "Intro Projects" github wiki page doesn't really distinguish 
between "here's a very beginner exercise for learning experience", 
"here's something that might be fun for you to do, and maybe someone 
else will use it someday", and "doing this would likely advance Racket 
significantly".


To respond to your question, some big things that would help make people 
reach for Racket first:


* Being there soon with a Web Assembly and HTML5 plus server full-stack 
story, in case developers respond favorably to that.


* Add support for developing general purpose slick iOS and Android apps 
easily (unfortunately, these effectively proprietary platforms with 
greedy app stores are very popular at the moment).


* Add support for developing certain kinds of money-making games (not 
general purpose apps) for iOS and Android (there is some money there, 
retro-looking graphics are OK, and students might be excited that their 
learning game school project can be launched in the app stores).


* Push DSL-based programming, for which Racket might already have the 
best technology.  (The other day, I saw someone looking to hire 
developers to use some DSL-based speculative methodology thing... in Ruby.)


* Find other application or technology niches that people want right 
now, and figure out some value-added support for them other than SaaS 
bindings that everyone else is doing.  Deep learning and other machine 
learning, traditional scientific/stats programming and visualization, 
voice AI-ish assistants, FPS video game engines, GPU targeting, etc.


* Simply doing a successful startup, and using Racket.  This gets Racket 
work paid for, you contribute back improvements motivated by real-world 
needs, and you talk in startup founder forums about how Racket was a win 
in some way.  Then we see whether it's still true that the startup does 
their initial version in a Lisp, then Yahoo buys it and rewrites it in 
Java. :)


* Similar to the startup bullet above, do "pilot projects" in Racket at 
your current company, or do your academic research with it.  One of the 
keys is to just use it, and the other key is to have funding for just 
using it.




--
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

[Eric Griffis]

Thanks for the quick reply. My goal is to make Racket more relevant for
general engineering and application development.

For example, I asked my scientist brother why he's using Python instead of
Racket on his next project. His response:

"but would I have to write my own routines for calculating mahalanobis
distance, or jensen-shannon entropy with bootstrap correction?"

Apologies for any confusion.

Eric


On Wed, Oct 11, 2017, 1:30 PM William J. Bowman 
wrote:

> Eric,
>
> I don’t mean to inadvertently kill any conversations, but I wanted to
> point out that there is an existing list of Racket projects on the Racket
> GitHub wiki:
>   https://github.com/racket/racket/wiki/Intro-Projects
>
> It hasn’t seen an update in a while, so some of those may be solved or
> have others working on them, but if you’re looking for projects I’d start
> by looking there.
>
> —
> William J. Bowman
>
> > On Oct 11, 2017, at 10:12 PM, Eric Griffis  wrote:
> >
> > Hello,
> >
> > My name is Eric and I love Racket.
> >
> > I am 39 years old and have been writing software for 30 years. I studied
> metaprogramming and taught programming languages as a grad student. My sole
> academic publication is on semantics and provenance for distributed data
> science tools. These days, I teach elementary school kids why and how to
> care about "coding," which means so much more than just banging out text.
> >
> > Racket is special to me because it makes programming fun again. When
> it's time to get real work done, I want more people to reach for Racket
> first. This is my goal, so I'm making this call for projects or project
> ideas as a conversation starter.
> >
> > Does a killer app or library sorely need a Racket alternative?
> >
> > Do you dread certain tasks that have you reaching for Python or
> JavaScript, or worse?
> >
> > Is your professional community holding out on adopting Racket, and do
> you know why?
> >
> > Any amazing projects pitched at the conference?
> >
> > I enjoyed following the graph drawing thread a few weeks ago. A serious
> attempt at "better than graphviz" could be fun and worthwhile.
> >
> > Eric
> >
> > --
> > 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.
> > For more options, visit https://groups.google.com/d/optout.
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Intro and projects inquiry

['William J. Bowman' via Racket Users]

Eric,

I don’t mean to inadvertently kill any conversations, but I wanted to point out 
that there is an existing list of Racket projects on the Racket GitHub wiki:
  https://github.com/racket/racket/wiki/Intro-Projects

It hasn’t seen an update in a while, so some of those may be solved or have 
others working on them, but if you’re looking for projects I’d start by looking 
there.

—
William J. Bowman

> On Oct 11, 2017, at 10:12 PM, Eric Griffis  wrote:
> 
> Hello,
> 
> My name is Eric and I love Racket.
> 
> I am 39 years old and have been writing software for 30 years. I studied 
> metaprogramming and taught programming languages as a grad student. My sole 
> academic publication is on semantics and provenance for distributed data 
> science tools. These days, I teach elementary school kids why and how to care 
> about "coding," which means so much more than just banging out text.
> 
> Racket is special to me because it makes programming fun again. When it's 
> time to get real work done, I want more people to reach for Racket first. 
> This is my goal, so I'm making this call for projects or project ideas as a 
> conversation starter.
> 
> Does a killer app or library sorely need a Racket alternative?
> 
> Do you dread certain tasks that have you reaching for Python or JavaScript, 
> or worse?
> 
> Is your professional community holding out on adopting Racket, and do you 
> know why?
> 
> Any amazing projects pitched at the conference?
> 
> I enjoyed following the graph drawing thread a few weeks ago. A serious 
> attempt at "better than graphviz" could be fun and worthwhile.
> 
> Eric
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Intro and projects inquiry

[Eric Griffis]

Hello,

My name is Eric and I love Racket.

I am 39 years old and have been writing software for 30 years. I studied 
metaprogramming and taught programming languages as a grad student. My sole 
academic publication is on semantics and provenance for distributed data 
science tools. These days, I teach elementary school kids why and how to care 
about "coding," which means so much more than just banging out text.

Racket is special to me because it makes programming fun again. When it's time 
to get real work done, I want more people to reach for Racket first. This is my 
goal, so I'm making this call for projects or project ideas as a conversation 
starter.

Does a killer app or library sorely need a Racket alternative?

Do you dread certain tasks that have you reaching for Python or JavaScript, or 
worse?

Is your professional community holding out on adopting Racket, and do you know 
why?

Any amazing projects pitched at the conference?

I enjoyed following the graph drawing thread a few weeks ago. A serious attempt 
at "better than graphviz" could be fun and worthwhile.

Eric

-- 
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.
For more options, visit https://groups.google.com/d/optout.