Re: [racket-users] How to store SQL query text outside Racket source code?

[Alex Harsanyi]

On Tuesday, August 1, 2017 at 12:11:24 PM UTC+8, gneuner2 wrote:

> Hmm.  A change to a query often also means a change to its arguments
> and/or its result columns, so I don't see that there is much utility
> in keeping the query strings separate from the program.  

I'm not trying to "abstract" the query away from the code.  I am trying to make 
working with the SQL code easier. I want to update my workflow, so that, when I 
see a line like:

(define query (sql-query "./some-file.sql"))

I can out the cursor in on the file name inside Emacs, type "C-c C-e RET", to 
open the SQL file, type "C-c C-c" and get the query results in the SQL Repl 
buffer.  I can than edit the file, and verify the query, than, I can just save 
it and the Racket program will pick it up.

> I certainly
> do test/debug my queries first using a SQL command line, but once
> they are working as I expect, I embed them into my application. 

I did the same thing, but this method has several limitations which show up 
once the SQL code starts to become more complex and you have to debug or update 
them:

* For large queries, the string is quite large and hard to read.  In particular 
neither DrRacket nor racket-mode will highlight the SQL keywords inside strings 
(and rightly so),
* If I want to debug, verify or check the execution plan of a query, I have to 
extract it in a separate file and run it,
* Once I update the SQL query, I have to put it back into a string inside the 
racket code, which is an error-prone task.

For an example of how this looks, have a look at 
https://github.com/alex-hhh/ActivityLog2, search for virtual-query and 
query-rows.  In my opinion, it is no pretty and I'm open to suggestions on how 
to improve this.

> I
> have a macro that allows me to write [nicely formatted] free-form
> SQL which gets converted into a query string suitable for use with
> the db library.

Could you share it?

> That said, if you really want to keep your SQL separate, I would not
> try to load query strings at the point of use.  Instead I would load
> all the query strings at startup and store them in a hash table with
> appropriate identifiers.  Then the query function could [minimally]
> be something like:

This, however will not address the workflow improvements that I'm trying to 
make, as per my explanation above.

Best Regards,
Alex.

-- 
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] How to store SQL query text outside Racket source code?

[George Neuner]

On 7/31/2017 10:46 PM, Alex Harsanyi wrote:

I'm trying to write a function to keep the SQL query text outside of the
Racket source code, as this would make it easier to write and test the SQL
code.

Instead of writing:

  (define query (virtual-statement (lambda (dbsys) "select ...")))

I would like to put the "select ..." part in a separate file and write
something like:

  (define query (sql-query "./some-file.sql"))

The "sql-query" definition would look like this:

 #lang racket
 (require racket/runtime-path)

 (define (sql-query file-name)
   (define-runtime-path rp file-name)
   (let ((qtext #f))
 (virtual-statement
  (lambda (dbsys)
(unless qtext
  (set! qtext (file->string file)))
qtext

Unfortunately, `define-runtime-path` can only be used at top-level, so the
above code does not compile.  It works fine without the `define-runtime-path',
I need to use it so they query files are found when the application is
compiled to a stand-alone executable.

Does anyone have an idea on how `sql-query` might be defined?

Thanks,
Alex.


Hmm.  A change to a query often also means a change to its arguments 
and/or its result columns, so I don't see that there is much utility in 
keeping the query strings separate from the program.  I certainly do 
test/debug my queries first using a SQL command line, but once they are 
working as I expect, I embed them into my application.  I have a macro 
that allows me to write [nicely formatted] free-form SQL which gets 
converted into a query string suitable for use with the db library.


That said, if you really want to keep your SQL separate, I would not try 
to load query strings at the point of use.  Instead I would load all the 
query strings at startup and store them in a hash table with appropriate 
identifiers.  Then the query function could [minimally] be something like:


  (define queryhash (hash))
 :
  (define (sql-query qident . args)
 (let ((dbc ...)
   (qtext (hashref queryhash qident #f))
   (if (and (connection? dbc)
qtext)
 (apply query dbc qtext args)
 (error ... )
 )))

Beware that I made this up on the spot - it is only intended to 
illustrate the way I would approach the problem.


YMMV,
George

--
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] How to store SQL query text outside Racket source code?

[Alex Harsanyi]

I'm trying to write a function to keep the SQL query text outside of the
Racket source code, as this would make it easier to write and test the SQL
code.

Instead of writing:

 (define query (virtual-statement (lambda (dbsys) "select ...")))

I would like to put the "select ..." part in a separate file and write
something like:

 (define query (sql-query "./some-file.sql"))

The "sql-query" definition would look like this:

#lang racket
(require racket/runtime-path)

(define (sql-query file-name)
  (define-runtime-path rp file-name)
  (let ((qtext #f))
(virtual-statement
 (lambda (dbsys)
   (unless qtext
 (set! qtext (file->string file)))
   qtext

Unfortunately, `define-runtime-path` can only be used at top-level, so the
above code does not compile.  It works fine without the `define-runtime-path',
I need to use it so they query files are found when the application is
compiled to a stand-alone executable.

Does anyone have an idea on how `sql-query` might be defined?  

Thanks,
Alex.

-- 
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] DSLDI 2017: Second Call for Talk Proposals

[Lindsey Kuper]

*
SECOND CALL FOR TALK PROPOSALS

DSLDI 2017

Fifth Workshop on
Domain-Specific Language Design and Implementation

October 22, 2017
Vancouver, Canada
Co-located with SPLASH

http://2017.splashcon.org/track/dsldi-2017
https://twitter.com/wsdsldi
*

Deadline for talk proposals: 7th of August, 2017

Well-designed and implemented domain-specific languages (DSLs) can
achieve both usability and performance benefits over general-purpose
programming languages. By raising the level of abstraction and
exploiting domain knowledge, DSLs can make programming more
accessible, increase programmer productivity, and support
domain-specific optimizations.

## Workshop Goal

Domain-Specific Language Design and Implementation (DSLDI) is a
workshop intended to bring together researchers and practitioners
interested in discussing how DSLs should be designed, implemented,
supported by tools, and applied in realistic contexts. The focus of
the workshop is on all aspects of this process, from soliciting domain
knowledge from experts, through the design and implementation of the
language, to evaluating whether and how a DSL is successful. More
generally, we are interested in continuing to build a community that
can drive forward the development of modern DSLs.

## Workshop Format

DSLDI is a single-day workshop and will consist of an invited speaker
followed by moderated audience discussions structured around a series
of short talks. The role of the talks is to facilitate interesting and
substantive discussion. Therefore, we welcome and encourage talks that
express strong opinions, describe open problems, propose new research
directions, and report on early research in progress.

Proposed talks should be on topics within DSLDI’s area of interest,
which include but are not limited to:

  * solicitation and representation of domain knowledge
  * DSL design principles and processes
  * DSL implementation techniques and language workbenches
  * domain-specific optimizations
  * human factors of DSLs
  * tool support for DSL users
  * community and educational support for DSL users
  * applications of DSLs to existing and emerging domains
  * studies of usability, performance, or other benefits of DSLs
  * experience reports of DSLs deployed in practice

## Call for Talk Proposals

We solicit talk proposals in the form of short abstracts (max. 2
pages). A good talk proposal describes an interesting position, open
problem, demonstration, or early achievement. The submissions will be
reviewed on relevance and clarity, and used to plan the mostly
interactive sessions of the workshop day. Publication of accepted
abstracts and slides on the website is voluntary.

* Deadline for talk proposals: August 7th, 2017
* Notification: September 11th, 2017
* Workshop: October 22nd, 2017
* Submission website: https://dsldi17.hotcrp.com/

## Workshop Organization

Co-chairs:

* Lindsey Kuper (lind...@composition.al), Intel Labs
* Eric Walkingshaw (eric.walkings...@oregonstate.edu), Oregon State
University

Follow us on Twitter at https://twitter.com/wsdsldi

Program committee:

* Nada Amin (EPFL/University of Cambridge)
* Eric Holk (Google)
* Gabriele Keller (Data61, CSIRO (formerly NICTA) and UNSW)
* Rebekah Leslie-Hurd (Intel Labs)
* Chris Martens (NCSU)
* Lee Pike (Galois)
* Jonathan Ragan-Kelley (UC Berkeley)
* Jesús Sánchez Cuadrado (Autonomous University of Madrid)
* Vincent St-Amour (Northwestern University)
* Philip Wadler (University of Edinburgh)

-- 
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] Seeking expert opinion on how Racketeering tames web development chaos.

[Neil Van Dyke]

Two things to add to my comments from early this morning...


* For servers, a nice don't-have-to-roll-your-own option sometimes is 
the Racket core Web Server.  I found it and SXML-ish HTML generation 
very productive for rapidly making an internal-use technical app -- 
probably more productive in that case than any other platform I could 
think of.  (For a prominent research organization, I'd developed 
specialized Web crawling and heavy scraping in Racket, to build a large 
text corpus database, and then I made a Web app for browsing 
the database and tagging it with semantic annotations.)  The Racket core 
Web Server also has an optional continuation-based state mode, which 
could be another one of those linguistic wins I mentioned.  What I 
haven't evaluated is how that performs at scale.


Of the two biggest Web servers atop Racket that I know of, 
news.ycombinator.com might still implement HTTP directly atop a socket 
(presumably with something in front), and a non-public family of Web 
servers has its own layers atop 
"http://www.neilvandyke.org/racket/scgi/; (I'd actually made the `scgi` 
package with a particular user in mind, to help them migrate a big 
legacy CGI(!) application smoothly).



* I mentioned linguistic properties as the reason one might use Racket 
for general industry use.  Another thing I've mentioned before is 
fuzzier: the developer community.  Racket attracts a small but strong 
mix of developers and researchers, and the culture is to welcome and 
knowledgeably help out others.  Do a quick Web search, then just ask 
your question on the email list, and you might get the actual developers 
or another expert responding.


By contrast, I was a very early Java developer (I first saw it when it 
was called Oak, I advocated Java for real application development, and 
my first apps required me to write even basic GUI widgets from scratch), 
but, after the "enterprise" popularity surge, there came a time when any 
Web search I tried about a Java question just turned up an impassably 
vast wasteland of people who didn't know what they were talking about.  
(Of course there are now small oases to be found, but it's tricky.)


Racket doesn't have that curse of popularity and ecology of many levels 
of commercial jockeying. :)  I'd prefer more industry opportunity with 
Racket, but I'd like that to happen without compromising the caliber of 
the community much.  For general industry use, community support isn't 
the top selling point, but I think most engineers and at least some MBAs 
would consider it to have significant real value.


--
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] Racket v6.10

[Vincent St-Amour]

Racket version 6.10 is now available from

http://racket-lang.org/

Note: Graphical Racket programs such as DrRacket are affected by a bug
in the Windows 10 Creators update which can lead to blue screens and
require reboots. We are aware of the issue, and have mitigated it in
DrRacket, which reduces the incidence of crashes. Microsoft has
diagnosed the issue and will release a fix in a future Windows update.
Additional details are available here:
https://github.com/racket/racket/issues/1671

* Internally, Racket's intermediate compatibility layer over
  operating-system facilities has been moved into its own library,
  "rktio", so it can be used in future Racket implementations. This
  change should be transparent, but the refactoring moves code that
  has many compiler and OS dependencies, so we expect a new glitch or
  two in less-common build and execution environments. Please report
  problems at https://github.com/racket/racket/issues .

* Racket supports cross-compilation of executables in more cases,
  including executables that depend on packages for foreign libraries.

* The `struct` form supports an `#:authentic` annotation to declare
  that chaperones and impersonators are never allowed on instances of
  the declared structure type. This annotation is intended for use on
  a library's internal data structures, where it won't interfere with
  contracts or other forms of extension at a library's interface. It
  can sometimes provide a small performance boost.

* RackUnit adds `nested-info` and `string-info` to grant custom checks
  more control over the display and layout of check failure info.

* The `raco test` command provides the `++arg` and `++args` flags to
  pass arguments to tested programs.

* Typed Racket has types for immutable, mutable, and weak hashtables; in
  other words the type `(HashTable K V)` is a union `(U
  (Immutable-HashTable K V) (Mutable-HashTable K V) (Weak-HashTable K
  V))`. Standard library functions may have more specific return types.
  For example, `hash-set` has type `(-> (HashTable K V) K V
  (Immutable-HashTable K V))`.  When an immutable hashtable flows from
  untyped code to typed code, Typed Racket may use a flat contract to
  verify its type (provided the table's key and value types are flat).

* The Typed Racket Optimizer is disabled in untrusted contexts (e.g.,
  sandboxes). This prevents unsoundness in the Typed Racket type system
  from being used to get access to unsafe operations.

* Racket's internal runtime adds a `scheme_atexit` procedure with
  identical behavior as `atexit` defined in libc.

The following people contributed to this release:
Alex Knauth, Alexander McLin, Alexis King, Andrew Kent, Ben Greenman,
Ben Noordhuis, Carlo Dapor, Conor Finegan, Daniel Feltey, Ethan Estrada,
Georges Dupéron, Gary F. Baumgartner, Gianluca Ciccarelli, Gustavo
Massaccesi, Harold Carr, Jack Firth, Jay McCarthy, John Clements,
Kimball Germane, Leandro Facchinetti, Lehi Toskin, Leif Andersen,
Matthew Butterick, Matthew Flatt, Matthias Felleisen, Michael Orlitzky,
Milo Turner, Mohsen Keyhani, Philip McGrath, Robby Findler, Rob Bassi,
Ryan Culpepper, Sam Caldwell, Sam Tobin-Hochstadt, Scott Moore, Spencer
Florence, Stephen Chang, Stephen De Gabrielle, Vincent St-Amour, WarGrey
Gyoudmon Ju, and William J. Bowman.

Feedback Welcome

-- 
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] Help: How to check a typed/racket type in an untyped Racket contract?

[Matthias Felleisen]

> On Jul 31, 2017, at 5:27 AM, James Geddes  wrote:
> 
> 
> Matthias,
> 
> Thank you, that's really helpful, both for letting me know I'm not being an 
> idiot (always welcome!) and for the example code, which makes me realise I 
> should learn about exceptions next.
> 
> Many thanks again,
> 
> James


Writing predicates via exceptions is a less than ideal situation. 

The proper solution would be to change Typed Racket to provide
the contracts that come with exported identifiers or similar 
solutions. 

But knowing how exceptions work is a ‘good thing.’ 

-- 
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] Racket summer school

[Matthias Felleisen]

The Racket Summer School on Semantics and Language was held in Salt Lake 
City last month. Sadly we had to turn away about half the applicants. So, 
If you weren’t able to join in person, you may want to check out the 
lecture notes and exercises at 

   https://summer-school.racket-lang.org/2017/

Enjoy! 

— Matthias, Matthew, Robby, Shriram, Jay and Justin 

-- 
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] Seeking expert opinion on how Racketeering tames web development chaos.

[Matthew Butterick]

> On Jul 30, 2017, at 8:02 PM, Sage Gerard  wrote:
> 
> Those of you working on the web know that Javascript went everywhere.

Like a puppy never housebroken.


> I see Racket can be used for web development, but is Racket really what I 
> need to meet the demands of multi-platform development while competing in the 
> market? Does Racket (or similar) sit at the next stage of evolution for the 
> multi-domain developer stuck in Javascript? If so, why?

Sure — just don't tell your boss you're using it. [0]

The life of JS has continually recapitulated the circumstances of its birth. As 
its creator concedes, "I had to be done in ten days or something worse ... 
would have happened". [1] 

But the cost of this speed was that "JS has a lot of stupid in it". [2] And 
living with "a lot of stupid", for decades, has been expensive.

In that sense, JS was more than a language. It introduced the foundational 
axiom of web engineering: that fast & stupid beats slow & considered.

Personally, I loathe JS. But I accept that the fast-and-stupid principle is 
legitimate. Moreover, it's probably been a more appropriate principle for the 
web than slow-and-considered, despite the costs (e.g., a culture of disposable 
code and near-continuous upheaval). 

Nevertheless, it is IMHO the opposite of what Lisps/Schemes generally & Racket 
in particular are about. Though I've mused about why these languages haven't 
been more popular in web engineering [3], it's not really mysterious: Racket 
encourages you to program in a slow and considered way. This is not what the 
web wants. (Though the creator of JS does credit Scheme as a positive 
influence. [4])

Still, the grave irony of the JS ecosystem is that even though firms have 
"normalized" on JS, it's such an unruly environment that it's like normalizing 
on Brownian motion. 


[0] http://beautifulracket.com/jsonic-2/intro.html 


[1] 
https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1021
 


[2] 
https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1020
 


[3] http://beautifulracket.com/appendix/why-racket-why-lisp.html#a_OyaFm 


[4] 
https://www.jwz.org/blog/2010/10/every-day-i-learn-something-new-and-stupid/#comment-1089
 


-- 
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] Re: Scheme and Javascript

[Greg Trzeciak]

On Monday, July 31, 2017 at 3:48:07 PM UTC+2, Hendrik Boom wrote:
> As I heard it, the people who made Javascript originally wanted to use 
> Scheme, and were starting to set that up when management decided tht 
> it had to look like C.  They ended up with Javascript, which does have 
> lists and closures and the like.  It's kind of a Lisp with C-ish 
> syntax.
> 
> -- hendrik

I've recently discovered a video recording from that meeting with management:
https://www.youtube.com/watch?v=BKorP55Aqvg

-- 
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] Scheme and Javascript

[Hendrik Boom]

On Sun, Jul 30, 2017 at 08:02:56PM -0700, Sage Gerard wrote:
> Hi!
> 
> New to Racket. Looking for expert opinion on my question, but I should give 
> some background.

As I heard it, the people who made Javascript originally wanted to use 
Scheme, and were starting to set that up when management decided tht 
it had to look like C.  They ended up with Javascript, which does have 
lists and closures and the like.  It's kind of a Lisp with C-ish 
syntax.

-- 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] Help: How to check a typed/racket type in an untyped Racket contract?

[James Geddes]

Matthias,

Thank you, that's really helpful, both for letting me know I'm not being an 
idiot (always welcome!) and for the example code, which makes me realise I 
should learn about exceptions next.

Many thanks again,

James


---
James Geddes

-- 
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] Seeking expert opinion on how Racketeering tames web development chaos.

[Neil Van Dyke]

You first have to ask yourself whether there's something about Racket 
that's a linguistic win for you -- say, you really benefit from the 
first-rate support for domain specific languages, or from having a very 
powerful Lisp family extension language, or you're doing nontrivial 
symbolic computation.


(My favorite example of this is from a public statement from ITA 
Software, who, paraphrased and IIRC, used the power of a Lisp to build a 
new node in the existing mainframe airline reservation system network, 
and they believed the only way it was possible was with a Lisp.)


That win from Racket has to be big enough you're willing to put in more 
effort on other aspects -- to figure out how to get Racket to do things 
for which you could easily find an off-the-shelf solution in some other 
language/platform.


If there's not that linguistic win, then you're better off using a more 
popular platform.


If there might be that win, rest of this email is more details...

Here's an example of the work: As a consultant, when I had to add a 
mobile app to one large and complex server-centric system that's 
implemented in Racket (and which had, speaking vaguely, a meta-model 
layer)... what I ended up doing was have the server generate the 
JS/HTML/CSS/etc. for an HTML5 app, from the current state of the 
meta-model.  In this case, I did it as HTML5 Offline stuff, including 
app updating, although I kept PhoneGap/Cordova as a backup plan.  Racket 
made this possible, because doing the generation was nontrivial, plus 
SXML is great for complicated HTML generation.  It was painful, partly 
because of the necessarily complicated nature of the system (no fault of 
Racket; you'd have this in any language, and it would probably be even 
harder there), and partly because Web apps are fundamentally an 
architectural mess right now (not Racket's fault, but bypassing Web 
technology and writing direct in Racket, with a nice UI toolkit, 
would've been much better).


To go back to your Desktop/Mobile/Server bullets, briefly and off-the-cuff:

* Desktop: Take a look at DrRacket on Windows/Mac/Linux, for a 
cross-platform desktop GUI app, from one source.  You can get a little 
more appearance polish and contemporary behavior, with work. The 
standard widgets are basic, plus a decent text editor one.  Not 
everything you see in DrRacket is easily reusable functionality. When 
the standard widgets don't do what you need, there is a canvas, and some 
3D support, so you can do *most* things, with some work.


* Mobile: This might see an improvement, in the future.  Matthew Flatt 
is doing hard reworking of the guts of Racket right now, and it's 
conceivable that sometime after, Racket could have a viable backend for 
targeting JS or Web Assembly.  For now, on Android, it's possible that 
Jay MacCarthy's recent work using Android NDK(?) might do what you need, 
although I think it's been focused on a particular user's needs.  I'd 
avoid the other education-oriented stuff.  Other than that, I think 
you're probably using any JS/HTML/CSS stack stuff talking to Racket Web 
services, and possibly having Racket help generate the JS/HTML/CSS.


* Server: This is most of what I've been doing as a consultant for many 
years.  There is a lot of rolling your own, but you can get it to do 
what you need.  For example, when a large system in Racket wanted to 
move to AWS, and do some unusual things, I had to implement the S3 
integration from scratch, and do some things to help move server and SQL 
to EC2, but it was doable, and I could also do the unusual things.  That 
AWS setup ended up being the first ever to get a particular fancy 
certification (I can't take credit for that).  In that example, the 
customer couldn't just install a new platform version or add-on that 
suddenly makes everything they needed to do work on this newfangled 
cloud thing, but, at the same time, they weren't captive to some 
off-the-shelf platform, and had the ability to do what they needed to 
do, and on their timetable.


Another thing to be aware of is that, right now, I don't think anyone is 
currently advancing Racket for industry work.  So, for the foreseeable 
future, you'll probably be rolling your own a lot, which can be good and 
bad.


Of course, as a technical consultant who prefers to work in Racket, I'm 
interested in a lot more industry uses of Racket happening, since that 
means some would likely pay me for advising, doing some of the 
architecture and/or trickier development work, and helping to fix 
problems that crop up elsewhere.  One thing I don't do is sales of the 
platform. :)


--
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] Re: Seeking expert opinion on how Racketeering tames web development chaos.

[George Neuner]

On Sun, 30 Jul 2017 20:02:56 -0700 (PDT), Sage Gerard
 wrote:

>I see Racket can be used for web development, but is Racket
>really what I need to meet the demands of multi-platform
>development while competing in the market? Does Racket
>(or similar) sit at the next stage of evolution for the
>multi-domain developer stuck in Javascript? If so, why?

I guess it depends on what exactly you mean by "multi-platform
development".  Most Racket code will run unchanged on any supported
platform.

However, Racket does not run in browsers, so it is not [yet] as
ubiquitous as Javascript.  As Alan mentioned already, there is work
being done to make Racket compile to Javascript, but AFAIK, it is
limited to text mode programs currently.

Text-mode applications are highly transportable.  As one data point, I
develop web database apps on Windows that are deployed as headless
services (daemons) on Linux.  The amount of OS specific code is very
minimal: in my case, it has been limited to needing to discriminate
some system specific error codes.

Racket has its own GUI library and application framework, and programs
written using them [try to] look/feel like native apps as closely as
possible on any supported GUI platform.  The library is generic and
doesn't include every possibility of every platform, but if you can
stay within its limits, your code will be largely transportable.

IME, Racket comes about as close to "write-once, run anywhere" as Java
ever could realistically claim.

YMMV,
George

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