Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Companies using Racket?
188 points by ctas on Nov 3, 2018 | hide | past | favorite | 132 comments
Hello everyone,

I'm looking for companies that are currently hiring Racket developers or did so in the past.

I created https://www.racketjobs.com, because I was myself interested in workplaces that use Racketlang commercially, but couldn't find any. After sharing the site on /r/Racket and a couple of other sites I got a bit more than 100 people to sign up for the newsletter.

If anyone knows a company, using Racket, or a place on the web where I can find open Racket positions, I'd be happy to hear from you. Of course I did my Google searches before.



We are working on a product written in Scheme. It's mostly just me currently. Not (currently) using Racket, but a set of libraries[1] on Gambit-C, as well as an interpreter written in C++[2]. We might take someone on board a few months from now (London/UK).

[1] https://github.com/pflanze/chj-schemelib [2] https://news.ycombinator.com/item?id=18045890


What about Racket's ability for arbitrary languages via #lang, not just macros? Are there any plans for this?

It's really nice to be able to do #lang c and just write C that is FFI'd into racket so you can avoid using an external toolchain to compile.


I don't really have a use for this. Gambit-C allows to include C files or also strings of C code from a Scheme module and builds it as one. I haven't used Racket's FFI though, perhaps the real benefit is from parsing the C code to auto-generate bindings? Generally I'd like to reduce the use of C code in case I want to re-target the code to run in a different, not C based, environment. chj-schemelib will need work for general consumption, let me know if you want to use it. (If you're talking about the interpreter in C++, it's the other way around, write FFI declarations within C++ to allow Scheme access to C++.)


Naughty Dog (game dev) have used it to some extent. This has been up on HN more than once. They have even done a presentation on RacketCon 2013. https://news.ycombinator.com/item?id=12203694


Thank you. I already watched the presentation, but couldn't find any open job positions in regards to Racket. I'll try to contact them directly and will see if I have some luck.


I think they may have stopped that after being bought by Sony? I don't think it is still around.


I think they still use it for scripting in their games. For things like AI, etc.


They are using an in-house variant of Scheme known as DC. There are a few pages about it in Game Engine Architecture, a book written by an engineer at Naughty Dog. https://www.gameenginebook.com/

DC is compiled to bytecode then interpreted. DC compiler is written in Racket.


We, at Linki Tools [0], use Racket for our main product: S10 [1]. Not hiring at the moment but most likely will in the near future. I always hire remote (contracting up to now) and by the time I have to hire remote for racket I don't think I will have any problems finding a fine dev.

If you're in the Frankfurt area, I will be presenting at the first After Work Racket [2] on Thursday, the 8th. Come join us.

[0] https://linki.tools [1] https://linki.tools/s10 [2] https://www.meetup.com/After-Work-Racket/events/253939676/


Hi,

I found your meetup and would really like to join - too bad that the company I work for is holding a conference at this day (www.talentthinking.de). So I may join for Episode 2.


I enjoyed using it in college during my programming language theory course. However, I thought it was meant to be more of an academic/teaching language. Why should a company use it over Haskell or Clojure?


You can write Haskell in the Racket environment[0].

Racket has a lot of well-designed and well-documented libraries that are a joy to work with. In his Racket manifesto Mathias Felleisen (author of The Little Schemer) describes how Racket is supposed to be useful for programmers at any level.

I'm currently working on a web app using the Datalog[1] back end. I guess that's very similar to Clojure's Datomic or core.logic, and I'm not sure which is "best", but Racket is certainly good.

[0]: https://lexi-lambda.github.io/blog/2017/05/27/realizing-hack...

[1]: https://docs.racket-lang.org/datalog/interop.html


> Why should a company use it over Clojure?

Not wanting to support the JVM ecosystem.


I'll add wanting to avoid any legal risk from its owner, who is very sue happy. They also got that copywritable, API ruling in one battle. I just stay away from anything Oracle owns. Using open standards future-proofs against this a lot.


I think racket would be a good choice for internal company tools. It’s batteries included philosophy allows you to create very complex apps with minimal effort.

Racket is significantly more expressive than clojure in many different ways (nice gui tools, very sophisticated macro system, good IDE)

I wouldn’t want to use racket for applications that would have thousands or millions of concurrent users. For programming in the large, clojure wins by a long shot.


> I wouldn’t want to use racket for applications that would have thousands or millions of concurrent users. For programming in the large, clojure wins by a long shot.

Can you explain why?

Because it's been used more in big prod envs? Or for reason intrinsic to the languages themselves? If the latter, which ones?


This is a bit funny to post in hacker news which was written in arc, a language built on Racket and serves large numbers of people.


Indeed, and Arc has some brilliant ideas, but if you ever tried to hack in it, you'd experience how dog slow it really is. But Arc's web framework is implemented in somewhat low level MzScheme and is entirely different (and much slower) than web apps in Racket's[0].

Part of what makes Hacker News fast is that the page only has 4-ish images (if you count the invisible gif that is used for indentation) and a tiny amount of JS.

[0]: https://docs.racket-lang.org/continue/


Yeah, but that's sort of the point: for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture. If a fairly inefficient language like Arc can handle HN loads (for the most part, at least), almost anything can.


> for most web applications, most performance issues are not the result of the implementation language but of the chosen architecture.

I don't think that's true (but I also don't understand what is meant by architecture in this context).

There's a simple file upload form example in the Arc community repository. It's so slow that it would timeout on files smaller than 100K. I tried optimizing the POST request parsing, but could still only barely get Arc to handle file sizes of 5M.

Tried making a similar simple file upload form in Racket, and it runs way faster. But it shouldn't be surprising that some languages are less efficient than others, right?

I'm also not sure that most web applications are text-only. Many web applications send and receive other things that plaintext.


> But it shouldn't be surprising that some languages are less efficient than others, right?

A long time ago I read a comment somewhere saying that Arc is interpreted (as in by a program itself written in MzScheme, instead of translated down to MzScheme), which struck me as odd but I didn't check back then, so now I finally went and looked through the Arc history[1] and release 0 already does the translation, so apparently that was just wrong. There can still be reasons why Arc could be slower, though, I remember PG's design called for overloading function calls so that e.g. hash table lookups could be written like function calls, and if implemented naively this could cost a slower than usual type check on each function call and prevent optimizations applied by the MzScheme/Racket compiler like perhaps function inlining. But just a different parsing infrastructure could explain it too (working on strings-as-vectors vs. lazy lists would make a large difference, but I couldn't get down far enough to see how that's implemented; srv.arc in parse-multipart-args uses regular expressions, not sure that's what you optimized?). Anyway, new code always has large potentials for optimization (early lisps were very slow, today's implementations are generally very fast; same was/is true for Java, JavaScript, ..).

[1] http://github.com/arclanguage/anarki


clojure has incredibly strong story for leveraging host platform ( jvm/js ) ecosystem


I think Racket is by far the better language. But the tools you have on the JVM are unparalleled. Racket's GC is not the greatest and the number of options you have to tune it are very limited. The JVM is very flexible and allows you to tune your application through a multitude of parameters.


simply because of battle-tested jvm.


The JVM?

What about the battle-tested Linux kernel? If you compile your racket apps to a native binary, you can run it directly on the Linux kernel, and benefit from 25 years of use in production! People deploy Golang and Rustlang apps everyday in prod using that approach it seems to work well for them. Note, both languages are younger than Racket.


Compiled Racket programs are nowhere near the speed of Rust or Go. Racket's GC is objectively much much worse than the JVM.

Of course you can serve millions of users with Racket, like HN. But the JVM today is much better choice. The JVM's GC is world-class and the number of man-hours put in it is probably many orders of magnitudes more than that of Racket's.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


So execution speed, fair enough.

FWIW, I've been staying away from Clojure because of the JVM. A lot of us are wearing the scars of the JVM battles!


If you need performance and want to avoid the jvm, there are also lisps like Chez Scheme and various Common Lisp implementations (sbcl, in particular, can produce really well-tuned numerical code).


... which is why Racket-on-Chez[0] is a really exciting development.

[0]: https://blog.racket-lang.org/2018/01/racket-on-chez-status.h...


"Keep in mind that the original goal is not to have a faster Racket, but a better-implemented Racket with acceptable performance."


racket compiled binaries are not "native", they are bytecodes jitted during runtime, and jvm's jit is highly performant.


Oh, so like python. Explains the poor performance. I did not know that. thanks.


As a broad approximation from the results of The Computer Language Benchmarks Game, Racket is 5 times faster than Python and 5 times slower than C. https://benchmarksgame-team.pages.debian.net/benchmarksgame/... (I can't find a direct comparison of Python-vs-Racket in the site.)

The difference with Python is probably bigger in programs with a big numeric part, and much smaller in programs with a lot of string. Take that number just as a general guide, not as a precise scaling factor.


> I can't find a direct comparison of Python-vs-Racket in the site

Now you will.


Why is not everything-vs-everything available?

Racket vs Python is a "common" comparison. I write the same comment once or twice per year :). (Probably because both are high level and have the batteries included. (The syntax is slightly different :) ))


1) Everything-vs-everything is available, here —

https://salsa.debian.org/benchmarksgame-team/benchmarksgame/...

2) People show interest in just a few comparisons (much much fewer than are currently shown).

3a) Everything-vs-everything is available, here —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

3b) Everything-vs-everything is available, here —

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...


no, python isn't jitted.


Great initiative. I often wonder why Racket isn't used more in the industry, especially when you see much more niche languages being used...

One note about your site: You are subscribing people to a mailing list without sending a confirmation email?


Thank you. I like the idea that Racket tackles each domain specific problem with its own language. I'd also be happy to see it used more often in the industry, especially since there's a growing ecosystem of libraries, tutorials, and other resources that ease the start into Racket.

Regarding the subscription: I'm using Mailchimp. A confirmation mail should've been sent out, if you subscribed. I will look into it. Thanks for pointing that out.


Racket is too powerful to be used by big corporations. The last thing a company wants is to have their rockstar programmer leave behind a terse, arcane, impenetrable walnut of an application.

Languages like Java make it much easier to treat your programmers as interchangeable parts.


Racket is too powerful to be used by big corporations. The last thing a company wants...

Ah yes, The Slashdot Cynicism.

Guaranteed to get a +5 Insightful.

What is your experience with Racket? Or failing that, Scheme? Or, failing that, Lisps in general?


Not exactly Racket. But with Perl. And the same argument.

Early 2010's, I remember my company had a fairly fast, stable and small(LOC wise) data feed processing application in Perl. It just worked, barely any bugs, maintained by 2 - 3 programmers.

Time came around, and your Director level people realized the teams were too small, programmers were having too much fun and more importantly it made programmers felt valuable and hard to be treated as kleenex.

They decided to give some Architect Astronaut love to the application. Then came in Java programmers. Code base size exploded by 500x. Design pattern floods followed. DI to manage complexity which shouldn't have even existed. Hundreds of classes to do things that could be done in hundreds of lines in Perl.

Managers routinely boasted how they managed to grow their teams, about their culture, and how big and great their teams were. They could never make it work as well as it did in Perl. I too moved on. But eventually I saw they just shut down the product.

No manager likes to see their work less valuable or better than that of a programmer.

Languages like Perl, Scala, Clojure, Racket, Common Lisp are never going to see decent adoption in the industry.


Used it in first year into to functional programming class. We didn't even get to see half the features of full Racket because the class used the student versions. Plenty of my classmates who had been programming in Java for years were getting overwhelmed by it.

I know from what I've read outside of that class that Racket is powerful enough to implement any other programming language as a library. A single programmer leveraging all these features can write an application that uses bespoke domain specific languages for every component. This is wonderful for a solo project but good luck passing that on to the new recruit.

P.S. guilty as charged. I am an old Slashdot reader.


There is life and interesting work in the industry outside the bigcorp java trenches, don't lose hope :)


I'm actually having a lot of fun at my job because I'm not actually a developer, I'm in change management. A lot of our processes are old, clunky, and involve a lot of manual steps. I've been writing Perl scripts to automate this stuff and my boss is loving it.


You are an "X who programs". Nice position to be in. Well done!


This is true issue irrespective of the company's bigness.


Racket has a few issues that make it hard to put into a production environment with a team of devs.

* Poor editor support. Apart from emacs and vi, many widely used editors support syntax coloring, but few do any proper indentation, and none (AFAIK) will do anything like intellisense. Only DrRacket really goes the distance on all those points and it hasn't kept up with the likes of Visual Studio Code or Sublime etc. You may say, just use Emacs! But if another dev doesn't use it they'll just ask for the language plugin for their current editor and then be mystified and frustrated at why they can't be productive.

* Poor performance. Out-of-the-box new Racket code will be slow. You can "precompile" it using Racket's built-in tools, which is great. But the process is complex and error-prone, and deploying your "precompiled" Racket code across a team in heterogeneous environment is not straightforward. My teammates are regularly stumped by how to keep our code running quickly. Racket also lacks effective profiling tools to address this.

That said, as Bjarne Strousup opined: "There are languages people complain about, and there are languages no one uses." I have used Racket in production environment for many years.


Just to add, there is also some kind of bias against Lispy languages because it looks different. People I meet who know about Racket (or other lisp dialects) just hate the "parens" or the prefix notation. Personally, I felt the same until I wrote reasonable amount of code, and that's why I think its a bias that one can get over with eventually.


I think by definition Racket not being used in industry makes it more niche than those "much more niche languages being used"


I just finished teaching Racket for 2/3 of the semester. I have never had a group of students hate their introductory programming experience the way that they did with Racket. 0/10 will never teach Racket again the rest of my life, no matter how much I enjoy functional programming.


We use Racket to teach functional programming in the first semester of the first year at my uni and we never have such horrible feedback from students. We use it again in a compilation course in the first semester of the third year of the same curriculum and it works well. Could you elaborate?


Not the querient, but my first experience with Racket was something to the effect of:

  > (cons 'foo 'bar)
  ! error: bar is not a list
There were several other condescendingly-reported gross implementation defects like this, most damningly a inability to define macros, which meant that Racket is not in fact a LISP, and the syntactic homogenity that makes LISPs annoying to work with (at the benfit of being able to generate and rewrite arbitrary program fragments on demand) serves no purpose whatsoever.

I later found out that this was apparently due to having been provided with a "teaching" version of the interpreter intended for beginning students (who presuably don't know any better), which makes it even worse.

I would definitely characterize my attitude toward Racket as "hate", and if acbart made the same mistake my (generally quite reasonable and competent) CS professor did, I wouldn't be surprised if their students felt likewise.


It does sound like you were expecting a full Lisp and instead were greeted with one of the Beginner Languages, intended to teach first time programmers in a very structured way. See https://docs.racket-lang.org/drracket/htdp-langs.html

The example that you give is not an error in full Racket:

  Welcome to DrRacket, version 6.12 [3m].
  Language: racket, with debugging.
  > (cons 'foo 'bar)
  '(foo . bar)
Similarly, full Racket has multiple, powerful macro systems, and more besides, deliberately excluded from the Teaching Languages.

* * *

I'm not an academic, but the community and core Racket team are incredibly supportive, and any Comp Sci professor running into difficulties teaching a Racket-based course can easily access plenty of support and guidance, starting by contacting the user mailing list.


> I later found out that this was apparently due to having been provided with a "teaching" version of the interpreter intended for beginning students (who presuably don't know any better), which makes it even worse.

I think you still misunderstand; racket doesn't have different interpreter/compiler versions with different language features, racket code explicitly can request different languages via a language directive (I think there is a corresponding UI option in the Dr. Racket UI.) Among the preinstalled options are a series of teaching languages designed to accompany the textbook How to Design Programs, among others.


That's unfortunate. Perhaps people should be informed about `#lang racket` first, but I'm not sure how you missed this. It's fairly easy to see in the documentation.


As you point out: Racket is different from the teaching languages.


Genuinely curious as to why this was so.

Did these students have prior programming experience? Was their reaction due to a particular fault of Racket or would they have disliked any language to which they were not accustomed? Perhaps their reaction was to the idea of functional programming which would have provided a distressing challenge to intuitions developed through object-oriented or imperative programming? What textbook did you use?


I would suspect that at least part of it is the same reason that I disliked having Pascal as taught as doing my programming introduction course: It's not a main stream language and it's sufficiently different that you cannot directly apply what you're taught in most commercial settings. The languages they will be using in the future, or expect to be using in the future are C-style object oriented languages like C# or Java (depending on where in the world you live).

It's not that languages like Racket, Rust, Haskell or even something like Prolog and other languages aren't interesting or useful, in many cases they're a better fit for your problems. It's just that without the background in the C-style and object oriented languages it's pretty hard to appreciate the more "niche" language and the problems they solve.


The industry will probably still be using C#, Java and JavaScript in the future - but those languages and environments evolve over time. Teaching the languages as it is used in the industry today is not preparing the students for the future. C# 3.0 is in many ways closer to ML than it is to C# 1.0.

I have seen developers complain they had to learn an unpractical "ivory tower" language like Haskell - and then the same developers get totally lost when C# introduced type inference and closures and deferred evaluation of queries.


>The languages they will be using in the future, or expect to be using in the future are C-style object oriented languages like C# or Java

Between Go Rust, F#,Nim, Kotlin etc I think ML-style syntax, and composition over inheritance is generally being preferred in a lot of newer up and coming languages. As well languages like C#/Java/Rust are so multi-paradigm these days the crossover relevance is very high from any one language to another.

I've never seen most languages as drastically different really. Lisps and Prolog certainly are, Rust is a little with the borrow checker, but otherwise I feel like people make much ado about "int x" vs "x :int" and "f(thing)" vs "thing.f()"


Go isn't a strong example of ML syntax.


As a counterpoint, I have taught Racket every semester for the last decade. Students are highly enthusiastic and give the course outstanding evaluations.

How did you approach teaching it?


I guess it depends then. Having been taught Racket in my intro programming class by Olin Shivers I can say I adored it and his class turns people into computer science majors using functional programming


That's sad to hear. I started learning Racket as my first Lisp. Not because I had to, but because I wanted to. I guess that's a major point, especially when it comes to exotic languages like Racket, that just don't look and feel like the everyday programming language you play around with in your college time.


Speaking for myself, it was hard to appreciate a language like Racket until I had a few years of experience (5?) solving problems with imperative languages.


Interesting, that's odd! Racket is taught to first years here too, depending on the sections some Haskell as well, it is pretty popular especially along with the "How to Design Programs?" textbook.


Perhaps you're not a very good professor.


Always a strong possibility. Although since I've always received high evaluations in the past, I'm not sure that's a good hypothesis.


I suggest getting in touch with Andrew Runka at Carleton University. He teaches with Racket, albeit at in the context of a programming paradigms course at a third year level. He is more or less successful in doing so.

Source: took the class with him.


Thank you for your advice. I am not going to do that. I have talked to many professors over the past decade who are successful in teaching the class.


I would love to have some elaboration. Why did they hate racket?


My son is changing out of computer science as his major after a semester of Scheme. Not sure it’s a direct correlation but I think it had a lot to do with it.


>>I think it had a lot to do with it.

Your son's case aside.

But CS for a while has been sold as something that anybody can do, is generally the easiest place to be where you can make big money. Even accidental, brush with hardships can make people quit as of this point.

Also read: The perils of Java schools: https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...


Some people think in dependency graphs. But it's much more common for people to think in steps. I put two apples in the cart, the cart has two apples; I put two more apples in the cart, it has 4. Something like Racket that forces you to think about what you want, rather than helping you iterate to get there, is going to be harder to teach to new programmers unless they already have this type of thinking experience from advanced mathematics etc. It's possible that the class wasn't primed to learn functional programming before imperative programming.


I think the idea is that a course using Racket or one of its teaching language has to teach that style of thinking, and any course that doesn't teach it will be doomed to fail. HtDP is a great example of how to do it right, which puts the design process in steps rather than the programming steps. I suspect the parent comment failed in this aspect of the course.


Possibly. Of course, there is little evidence that the HtDP curriculum "does it right" while all others fail to do so. It seems to have a strong cult following, with little evidence to back up its touted advantages over other approaches.


I never said all others first of all, I just know that's one example I have a lot of positive firsthand experience with. Generally as well it's not like curriculum approaches have any evidence either way, so while there may not be evidence, I would ask what curriculum does have evidence that it's better than another. I've done some digging explicitly in that area and there's really no good evidence for anything from language choice, object oriented vs functional, everything. Not surprisingly either, it's quite the hard problem to solve and get rid of bias towards one approach in a study to start with.

I'd say this though - a "cult" following I would note as a likely symptom of a good curriculum, one that does such a good job that it inspires those that go through it to advocate for it strongly. Is that not itself evidence of some indirect sort? I'd say it's better than most out there.

In terms of its advantages, I think a reasonable person can decide if both the advantage is actually an advantage and at least gauge how a curriculum fares on executing on the advantage. For example, the ramping up of difficulty from the teaching languages. Instead of saying "theres little evidence", I would go through the curriculum and its advantages (and disadvantages) like that.


Please say more - what was so hateable about it?


Did the students give specifics?


Why didn't they like it?


We used its predecessor Dr. Scheme at Rice University around 1997-1998. It was weird for those of us with previous programming experience but I don't recall us hating it. I didn't hate it.


I'm a big fan of lisp but I dislike racket. In general, I recommend clojure. If you're motivated, arc on top of common lisp.


Why do you dislike racket?


I don't remember everything on top of my head unfortunately, but it was things like, weird choices all around like long names, no real OS threads, that kind of stuff. Sorry, I don't remember, I just know I tried it a couple of times and disliked it.


I have to agree on you regarding OS threads, although there are places, but they're processes. For long names, most names have an abbreviation like call-with-current-continuation has call/cc, and in any case, you can make your own abbreviation using make-rename-transformer so this shouldn't be an issue


Why would one bother when clojure has core.async, short names and everything else?


The tooling is complicated with Clojure. If you are teaching an introductory class, having a single simple install of DrRacket is a big plus.


Good point. Though I'm not so sure it's such a big deal in comparison of using a language that's not entertaining.


Because racket has hygienic macros and #lang, and syntax-parse.


I have a work available at the moment, but a bit quirky as we're using our own novel Racket-influenced scheme dialect for business workflow, coupled with Python. Happy to chat.


Great to hear. How can I contact you? You can mail me at cihan(at)tas.fm


Just sent you an email, thx.


I was surprised to see that you charge $100 for a 60-day post. Is that typical of job posting sites?


It's actually cheap compared to other job boards, which usually charge 250+ for 30-60 days, giving you access to a pool of highly relevant developers. Not trying to say, that it couldn't be free of course.


A long time ago, I was using racket at the largest hospital in Massachusetts analyzing DNA sequences of MS patients. I used racket to create a GUI that allowed non-technical biologists to create custom bioinformatics pipelines.

I found Racket to be great and highly productive. If you are looking to use racket at work I would recommend you look into working as a software engineer for academia.

If you are the only engineer around, you get to use any language that you want.


To just offer a possible contrary perspective: nobody else is around to tell you you're using the wrong tool for the job.

There's many fine options for each domain and yeah, you get the choice of them if there's no established languages. But be careful not to go off the deep end on using your favourite langauge for everything.

On small teams it becomes increasingly important to endeavour to objectively scrutinize your own choices as best as possible.


I agree with you, though being a lone developer sometimes allows you to be more flexible in the tools you use. At the hospital I used Racket, Haskell, C, and R. Because my programs didn't need to talk to each other, I was free to write each utility in what best suited the job. On a team I think there's a lot of pressure to just use what everyone else is using, which can lead to sub-optimal results.


Yes, but if the hospital ever needs to replace you they are SOL


This is a common argument, but I've not seen a great deal of evidence for it on the ground. Rather, there seem to be a decent number of LISP enthusiasts out there who end up working with more mundane languages in their day jobs. If you advertise a LISP position, and make it clear that it really is going to be mostly LISP rather than just a keyword to generate excitement, I can pretty-much guarantee that you'll get applicants.

In locations where developers are very thin on the ground (i.e. not Massachusetts...), things might be harder. There's always the possibility of hiring remote.


Any developer worth their salt should be able to pick up a new language in a couple days. I'm not sure why some developers are so adverse to learning anything new.


I know Scheme, I am currently learning Elm. I like picking up fun languages. I also like working with them when possible.

But I think the implication that a hospital board can confidently hire a developer that is "good", or one that will make good decisions in their behalf is wrong. For proof, see the OP of the thread.

Their decision, I believe, directly harms the hospital's interests. He has essentially become irreplaceable, because they don't have the necessary skill set to confidently hire someone who will be able to replace them. Even if, in the best of cases, OP leaves for a better paying/what have you job hiring someone to fill their void will be hard.

That's not what bothers me most, however. It's the attitude. It's us as developers going: "I picked the best tool for the job, and thus this solution will be intrinsically better for the business". Like we're doing them a favor.

We're not doing them a favor, even if the tool is superior for the use case the difficulty of finding other people who could take over you introduces an amount of risk that almost no business that understand the full implications would allow. Worst case scenario, the tool(s) might need to get re-written from scratch. And the new versions could have bugs the old ones don't, or poorly handle all the one million edge cases that pop up over time.

But the arrogance to say we are picking the best tool for the job, while really picking a tool we wish to use to satisfy ourselves intellectually is what bothers me. If you are forthright and say "Hey, using this will make me happier at my job. And I will thus presumably perform better, and I'm the person in the position to choose what we use" I think that's fair enough. Again, it's the conceit of looking at a business person in the face, and telling them that this tool is the best for the job, when it clearly isn't.

It might be the best tool to programatically encode the job. I can concede that. But I feel that is willful blindness on the part of us programmers to the needs of the business in the pursuit of serving ourselves.

And again, that bothers me. But you might say "Fair enough, and I was in the position to make that call, so I did". It's not like we exist to serve businesses. But to reiterate for the last time: To say this is being done because it is the best suited for the job at hand is wanting to have your cake, and eat it too.


This just isn't true. There is a reason people look for devs with years of experience in a certain stack.


At work we use Scala in a very functional style and Akka. Not a single dev on our team (including me) knew Scala when they started. Everyone was productive with the codebase and programmed idiomatically within a matter of weeks.


I imagine the team was familiar with writing Java, which makes moving to Scala the easiest possible language transition besides maybe a move from C# to VB.NET. Switching to a completely different ecosystem, such as to R, Racket, Haskell and C takes at least twice as long. And could be much longer if you're relying on large framework changes, for instance if you're switching from QT to GTK+ or WPF.


Those developers ain't worth their salt.


Are you arguing that developers graduate and hit maximal productivity in any stack in 3 weeks?


The language itself, maybe... The ecosystem? Forget it.


How lucky are you to test your subjective theories [with] someone else's dime.


I don’t believe it, the internet is full of people that struggle to learn Haskell and even R. For many, it’s not that easy.


But they only need to find one such developer; no need to employ the whole Internet.


That's easily said but what's usually meant is that any programmer of a blub language (http://paulgraham.com/avg.html) is able to pick up another bulb language in a couple of days.

Racket doesn't fall into the category of blub languages.


This. Racket simply allows you to address any problem domain in an even more powerful manner than other Lisp's: simply by creating a truly independent parser and interpreter that still has nice interop with the rest of racket.

Not to mention, the metaprogramming facilities are the most advanced in the world.


Having discovered the TCL programming language because of a single person using it in a bioinformatic lab I can second the recommendation.


We detached this subthread from https://news.ycombinator.com/item?id=18370226 and marked it off-topic. Not that Tcl isn't a fine language.


TCL/TK is probably one of the most underrated GUI frameworks out there.


I once tried it; well, Expect specifically, which is really an executable wrapper of TCL with a library loaded. I ended up ditching it and using ruby's "expect" library. I remember having issues with scope. Expect functions you call would manipulate the scope of the caller. So when I wrapped some code in a function and called that in its place, things wouldn't work, because state wouldn't be handled in the same scope anymore. That means I wouldn't be able to abstract anything. No reusable units of code. I'd have to keep expect's calls all in the same scope.

TCL and Expect seem pretty cool in concept, but Expect's implementation seems awful.


Tcl/Expect are both heavily used at Cisco for router and switch automation. But recently, we've been shifting to Python for testing and automation, which I think is a step in the right direction (e.g., pyATS[1]).

[1]: https://developer.cisco.com/site/pyats/


I used tkinter python bindings, very fun. Zero mental burden.

Also tk was used as Digital Domain (James Cameron FX company) Nuke compositing software. Sooo.. I guess it's fine.


TCL/Tk is used heavily in finance/wall street.


No it's not. Languages most commonly used in finance are: C/C++, Python, Java, Scala, Julia, Matlab, R, and KDB.


Where? Aside from the few OCaml fans, I’ve only ever seen bog-standard Java/C++/Python


I don't know about finance, but I think it's used heavily in aviation.


It's used heavily at Intel, in hardware verification.


Virtually all EDA (electronic design automation) tools include a Tcl shell that echoes back any GUI action as a Tcl command. This makes it very easy to write Tcl scripts that perform repetitive actions (e.g., load HDL source, compile design, simulate, check value of signal).


Aplusdev.org used the tk part. While APL is used heavily in many financial institutions I am not sure how widely A+ is used.


A+ was invented by Arthur Whitney for JP Morgan (iirc). I'm sure they have some things in house still using it, but that it's mostly been deprecated by Whitney's Kdb+ environment which is sold by Kx Systems. It is the APL like "K" language bundled with a database generally run on SSD. I believe it is quite pricey.


According to the aplusdev.org site it's Morgan Stanley. I have zero knowledge of what the current status is inside that or any other company.


Ah, similar name. Thanks for pointing out my mistake.


Another programming language?


Racket is unlike many other programming languages, firstly it's a lisp. Secondly, it features a builtin language framework that allows you to seamlessly interop different languages through racket. Once you learn racket you realize that most other languages are just macros in racket, or a #lang in racket, and that their unique implementations are mostly quite wasteful, as they make interop hard.


Racket exists since 1995




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: