Does Anyone want to Collaborate on a "Big" Project to Show Racket Can Work in Production?

General
1

There is an interesting call to action on the Racket subreddit that would be better placed here where Racket discussion is more active:
Does Anyone want to Collaborate on a "Big" Project to Show Racket Can Work in Production?

3 Likes
2

Hello!
I don't want to copy paste that super long post of mine here. But I'll summarize:
Killer apps, amirite?

1 Like
3

(Didn't read the article first... it would have been worth your while to copy and paste it in. Still would be.)

I'm skeptical about this on several levels:

  1. "Non-mainstream" languages are regularly dismissed as toys / only written by academics / not ready for production / impossible to hire people to work on. People come with the same attitude toward languages like Common Lisp and Haskell for which that take is (imo, without a question) demonstrably false.

  2. What is proof? In order to have an interesting dialog, you would need a "disbeliever" who was willing to engage in dialogue to set the parameters of what constituted an acceptable level of complexity.

    Suppose hypothetically you find someone who looks at work like the Sham project "A DSL for Fast DSLs" (sorry, only an arXiv reference) and is sticks to the claim "this is just a toy it's not ready for production"... well, what are you going to tell them? My assumption is that is already a 100x better product that I'm going to make as my proof, regardless of what's wrong with it. You've got to have some parameters.

  3. Is making money proof? People make money with PHP and JavaScript. Just reading that stuff makes my eyes burn. Sometimes success comes from a historical accident. That's not good enough for me. On the other hand, if I roll out my $10k MRR business with Racket providing all of the core service, I know people are going to tell me "yeah sure, but you would have gotten it running 3 months faster if you had just stuck to Python" or "$10k/month is still toy money". Maybe having a bunch of money rolling in would be proof enough, but I am running the business to make money, not demonstrate that Racket is production-ready. (Mic drop.)

There's more to say on the other side, in support of the idea of a big Racket project, but this post is already "tl;dr". Hope you enjoyed it.

Interesting Reference

3 Likes
4

These are great counter-points. I like that you highlight that, at some point, we would have to specify the acceptance criteria ahead of time. Otherwise we are playing a frustrating and potentially unwinnable game. It is easy to have accidentally let the goal posts keep moving with an ill-formed call-to-action. I saw that when using Haskell in my graduate studies as well, even when Facebook and Microsoft were/are using it.

I guess making money might be a proxy for an incoming programmer's belief that "this will be useful to my career". Non-applicability to career development seems to be an anxiety many of my students have.

I like your bolded comment a lot because I'm wondering if there is a parallel around the purpose of writing any code in the first place. That is, is "I'm running a business to make money, not demonstrate that racket is production-ready" kind of like "I'm making an application because I want to make the best version of this thing, not to show off the tools I made it in"?

It's kind of like "I want to get rich" and then all the guru's say "if you have no passion for what you're doing, and just want to get rich, you'll never get rich". Idk, is that too philosophical? haha.

5

On a related note, I started building the Frosthaven Manager to learn how to male GUIs and to build a helper for my board game group. I also got the chance to practice LOP; software engineering on a larger, long-term project; and web-server programming. Now I’m getting ready to present a paper on functional GUI architectures stemming from this project and from Bogdan’s GUI Easy (better announcement coming when I get to a computer). We use this every week to play our board game.

So, is there anything left to demonstrate? Plenty of Racketeers are academics and plenty are industrial, and a happy lucky few use Racket for their primary source of income. Racket exists. That is enough.

3 Likes
6

Hi :wave:

I thought about this call to action slightly differently, coloured by my experience with enterprise applications: I find them fascinating because they do so many things and invariably often have a number of languages (like the example of game studios) to define workflows, reports, forms, data, templates, mappings. (I'm being deliberately broad in my definition of a language to include graphical -builder tools.)

Enterprise applications are specialised and they are everywhere - I'm familiar with hospital systems and (to a lesser extent) lending libraries - but I see them everywhere I go.

I think a great community project would be to build a bare bones enterprise system using Koyo and then extend it for different domains.

Stephen

7

So a very small and modern equivalent of something like Apache OFBiz or ERPNext?

8

Probably start smaller - say a toy library for a kindergarten.

You have

  • Users - ‘toy librarians’
  • Customers - who borrow toys
  • Assets - toys

Users can

  • add a toy to the collection
  • remove a toy from the collection
  • add a borrower
  • add a user
  • lend a toy to a user
  • checkin a returned toy
  • etc.

S.

9

Sorry - I thought about this and realised I failed to communicate my ideas.

I should have said yes:

  1. These sorts of systems have lots of opportunities for language oriented programming both in their construction, and in the provision of end-user programming - their biggest competitor is Microsoft Excel in that respect.

  2. Start with one component. The library example was meant to demonstrate that there are lots of different types of organisations and their enterprise systems have a different mix of components to those offered by OFBiz or ERPNext. A hospital would use some of the components, but would have other systems for other aspects of the work they do.

‘Help desk’ (ERPNext) might be another good starting point due to familiarity.

Why do this?

  • a lot of developers work on these sorts of systems - developing the product as a vendor is the obvious one, but developing on top of these platforms is also a job people do.
  • end user programming is an interesting challenge in language oriented programming

Best regards

Stephen

10

Is there anyone interested in making a modeling/simulation project like Simulink or Modelica? I am major in mechanical engineering (vehicle dynamics, to be specific) and use Simulink a lot. I've hoped that there will be some alternative. I read SICP and found the ability of LISP to build a circuit simulation system. I think it's possible to build a more general simulation system using Racket. But I don't think I am able to build a whole simulation system. So if someone is interested to make such a system, I will be glad to participate in the project. I can write some simple program like this: chemPolonium/leetcode-racket: Solve leetcode problems using Racket (github.com)

Some part of the system in my opinion:

  • a library or language to build a block/system
  • an ODE solver
  • some basic library blocks like gain, int, sin, etc
  • maybe a GUI in the faraway future

A glance of Simulink: a system is modeled using some blocks and signal lines.
image

By the way, another reason for this thought is: I am from China, maybe someday I can't use MATLAB just because the Entity List...

2 Likes
11

It's not a Racket project, but a Gambit project, and I'm not proposing to do anything on it, but it may still be of interest. I heard about it at a Gambit meeting held a few years ago.

A company was findint their Enterprise Resource Planning software wa etting out of hand. It was written in C++.

Someone got the idea of doing further development using Gambit as a macro-style preprocessor.

They discovered that it was soetimes easier to rewrite a system component in Gambit nd have it translated into C++ than to fix bugs in the original C++.

Over the next two years they started doing it systematically.

The final Gambit source code was almost an order of magnitude smaller than the original C++ code and ran faster and more reliably.

I wish I still had a link to the meeting proceedings.

-- hendrik

1 Like
12

Jazzscheme - Scheme workshop 2010?

Slides: http://www.schemeworkshop.org/2010/cartier-guillemette-presentation.pdf

And a paper behind a paywall :face_with_symbols_over_mouth:

13

My mistake it is available http://www.jazzscheme.org/files/sfp.pdf

14

This looks like the project I was referring to. But the document I (mis?)remember emphasized how they migrated the ERP system rather than the JAZZ system's development.

-- hendrik

15

Hi @chemPolonium

Thank you for responding - sorry I've taken so long to answer.

I think this is a good idea, and a great addition to the tools to support science and engineering in Racket.

Did you try implementing the SICP circuit simulation in Racket( #lang racket) or #lang sicp? - Either way that would be a great starting point.

Best regards,
Stephen

Apologies for the badly out of date Racket Wiki page: Scientific Computing · racket/racket Wiki · GitHub

16

In my opinion, if you want to convince anyone that Racket can be used in production, you have to point to Racket software actually in production. Having a "demo", "proof of concept" or something presumably "production-ready" (but not actually used in production) isn't convincing enough if your goal is to get people to use Racket in production.

This also implies that this software must be maintained in the longer term. Otherwise it can come across as "Yes, there was some production software, but somehow it seems it didn't work out." I think this perception would be worse than when not having written/published the software in the first place. No longer using the software in production may be perceived as a "failure" of Racket from the outside, even if there were good reasons for no longer maintaining and/or using the software.

Therefore, if you want to use Racket in production, go ahead and do it. But not if seeing Racket in production is the only motivation for the effort.

1 Like
17

Although I'm quite sure you could do something like this with Racket, I think it would be far from trivial. I think the "benefit for the world at large" would be much higher when contributing to one of the existing projects along these lines. When looking for such projects, I found these starting points:

Some of the links point to more projects that I haven't included in the above list.

2 Likes
18

To add my 2(€)c. here. I do not see the need to "show" anything.

Contributing to any projects is always a nice idea. However, I think the call is more generally for "success stories" - although it is not phrased that way.

I am running a Racket-powered company and although most of the code we produce is kind of a "trade secret" (it is anyway VERY tightly tied to the customers' business processes) and therefore it is not possible to publish it as "success story" with source code on github.com :wink: I can share some interesting numbers (public anyway if you know how to search the official business registries here).

For the past four years, we have two full-time Racket developers for mostly customers' projects. Add to that one full-time front-end developer (that is React.JS, don't ask, please), one systems admin and one person as administrative support. We are a small company, yes. However, all our invoices for development (which is the major source of our income) come from Racket-backed projects.

So Racket-backed projects can sustain 5 people and although we won't become billionaires this way, we don't care. It gives us all enough to do whatever else we want to do which - in my opinion - is possible only because of Racket ecosystem.

In addition to the economical incentive, we can have fun solving interesting problems which other developers found impossible to solve. In a different thread, my package futures-sort was mentioned. Btw, Racket CS sort outperforms it in 99% situations :wink: But for the rare situations where you need to pack data into 61 bits and work with 2^30 or more values like that, it is blazing fast compared to any alternatives the customer had (minutes compared to days). Yes, I wrote "customer". This library was developed for one particular customer to aid with optimizing issued invoices used as a collateral for operating loans. And only thanks to this library the customer has been able to secure about 20% more money for its operations - that is roughly 1M€ more to use every month (I leave aside whether that is a good or bad thing, the task was to optimize it that way). That was in summer of 2018 - they are still using it today and yes, we've done much more for that customer since then and we've been solving only interesting (yes, hard, of course) problems for them.

To sum it up: the "Big Project" is called Racket. We all try to collaborate on that. Sometimes with a question, sometimes with a suggestion, sometimes with documentation and sometimes with actual code as well.

And I know I am not the only one with this experience.

5 Likes
19

I don’t think there are wrong reasons to write code!

If someone wants to write something to prove it can be done then I say ‘go for it!’

Larger projects are daunting so using the Racket Discourse or Discord to find collaborators is a great idea.

Even if you don’t succeed you will have made a friend or two and learnt something. It’s better than watching Warrior Nun on Netflix.

Best regards

Stephen :beetle:

PS You will have a better chance of attracting collaborators with a working prototype, so pick a domain you have some knowledge of.

20

Good point. I may have worded my last sentence too strongly. :slight_smile:

Of course I don't want anyone to keep from working on what they like. My point was that convincing people of Racket's production value may be harder than it seems and that may affect the projects you want to spend your time on.

1 Like