41–50 of 115 posts
Sometimes maximum precision means having a first-class typechecker & type inference. (You could build some of that too in Racket if you really need to. Of course, that code itself will not be verified or typechecked.)
> Why aren’t these languages DSLs?
They aren't DSL's because they need statically-linked binaries, and good error messages, and then your task is not as easy as desugaring to a LISP/dynlang.
I think when people think about "programmers/developers" vs "computer scientists", this is where the difference could really show up in the future. A developer who knows how to code and hack may not have the skill/design knowledge to properly create a language/DSL, perhaps making a monster in the process. A well trained computer scientist (academic, self taught, doesn't matter) should have those tools and more importantly the design know how. A lot of teaching (again in both academia and not) really lacks on teaching good design for programming generally.
I think we're already starting to see this difference show up with libraries and frameworks (somewhat already DSL's themselves), and if we keep moving towards the direction of DSL's I think you will find many of the bright programmers of tomorrow going away from writing code to make things but instead code to make languages to make things. The final step of code to thing (from a technical perspective) seems to become increasingly boilerplate more than ever before as tooling keeps expanding. You still need to know the deep internals for large scale things, but it's never been easier to spin up a quick project that "just works" and does quite a lot. If library/framework/language creators do their job, this should only get easier.
At a certain point I wonder if the actual programming ever becomes a "lower tier" of the software world.
> maximum precision Sometimes maximum precision means having a first-class typechecker & type inference. (You could build some of that too in Racket if you really need to. Of course, that code itself will not be verified or typechecked.) > Why aren’t these languages DSLs? They aren't DSL's because they need statically-linked binaries, and good error messages, and then your task is not as easy as desugaring to a LISP…
Easy, just used typed Racket :)
I was thinking recently about why I find programming languages so interesting. The answer I came up with was that programming languages allow you to create your own reality. You get to define how things work in this reality. Want functions to be values that can be arguments and return values? Sure! Want a lot of crazy symbols to do complicated math? Go for it! Want everything to be dynamic? Why not. The caveat that c…
Remember the first couple of programs you wrote? I bet they were all quite similar.
Earlier quoted context omitted.
I think racket makes it simple to compose your language implementation modules. So e.g., hygiene could be imported (with minimal adaptions to your syntax/binders).
Yeah, that's true. I would love to read an article about that with practical examples, i.e. showing that language composition is really a common and needed pattern (not just a theoretic concern, ... are LOP users really composing several language modules often?), and how Racket enables it.
https://www.tolongtangtugas.web.id/2019/02/master-present-pe...
> maximum precision Sometimes maximum precision means having a first-class typechecker & type inference. (You could build some of that too in Racket if you really need to. Of course, that code itself will not be verified or typechecked.) > Why aren’t these languages DSLs? They aren't DSL's because they need statically-linked binaries, and good error messages, and then your task is not as easy as desugaring to a LISP…
> Of course, that code itself will not be verified or typechecked. Easy, just used typed Racket :)
The fact, there are many people here discuss it ..
In addition, I try to maintain my English by writing some articles, such as
1. https://www.tolongtangtugas.web.id/2019/02/master-present-pe...
2. https://www.tolongtangtugas.web.id/2019/02/belajar-asyik-sim...
See that, if you like .. thanks ..
An interesting tangent I think about sometimes: I think when people think about "programmers/developers" vs "computer scientists", this is where the difference could really show up in the future. A developer who knows how to code and hack may not have the skill/design knowledge to properly create a language/DSL, perhaps making a monster in the process. A well trained computer scientist (academic, self taught, doesn't…
The author of Beautiful Racket, Matthew Butterick, is a lawyer and a typographer. He is not a computer scientist. And yet, he designed a DSL called Pollen for creating web-based books. Pollen has been quite successful within the Racket community.
My understanding is that Racket is predicated on the idea that people like Matthew, as much as people like your computer scientists, are the best authors of DSLs. They are the ones who understand the domains they're working in. If the division you predict ever does exist, it is because the tools have failed to make people who are not computer scientists capable of creating the DSLs they need to solve their problems. It's not because languages are inherently better designed by experts in the domain of programming languages.
Earlier quoted context omitted.
> Of course, that code itself will not be verified or typechecked. Easy, just used typed Racket :)
Ok, so now you have Typed Racket (that last point was a relatively minor comment on the larger argument). Does implementing the above then correspond to the strengths as described in LOP?
About a decade ago, I would have agreed with this 100%, and I still am fascinated and, quite frankly, awed by Racket and LOP (and looking forward to Racket Fest 2019 here in Berlin[1]). But. (You knew there was a "but"). While I don't quite agree with the assertion that with the right tooling (so: this tooling), creating a language is as easy as creating a library, I don't think it would solve our problems even if it…
I largely agree but then I enter the modern ops stack where templated yaml is the lingua franca. It’s incomprehensible and for each system you are operating you have to learn some arcane yaml incantations that have dramatic impact on your production systems. It’s a world crying out for a set of well factored dsl.