131–140 of 177 posts
Earlier quoted context omitted.
That makes no sense. Which Common Lisp implementations contain a compiler written in C or Fortran?
I should have been clearer: written partially in C or Fortran. SBCL, for example, has C bindings in the /runtime subdirectory.
So nothing to do with SBCL's compiler (which is somewhat confusingly named 'Python' and written entirely in Lisp), then.
I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…
I would also add a build system to that list, a tarpit many engineers have fallen into. > not sure that there is a difference to compiler as stated in the article It's hugely different. If you're building a compiler for an existing language, you inadvertently signed yourself up for implementing and supporting the entire language, which is a pretty large engineering task. But if you design a new language, you signed u…
Some of us might argue that you have to do that anyway, for any software you write. In fact, a similar argument might apply to your first point.
On the other hand, the last three points are really not requirements unless you are creating a general purpose language and have a large audience.
I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…
IMHO "programming language" would refer specifically to the grammar, type system, semantics, keywords, etc. and "compiler" would refer to the implementation that takes something written in that representation and outputs some type of executable. A pedantic distinction but probably a useful one, especially given how some languages have multiple implementations of their standard. The Programming Languages course I took…
1. They are one of the most researched areas of CS with a large amount of educational materials, tools, and community knowledge to help.
2. They map to any problem involving transforming an input into an output (hell, any problem transforming an input to an output is a compiler or interpreter).
and Your Program as a Transpiler: Improving Application Performance by Applying Compiler Design https://www.youtube.com/watch?v=TWfigR9wGsA
Your Program as a Transpiler: Applying Compiler Design to Everyday Programming https://www.youtube.com/watch?v=BUrY6On1SxM
the second in particular is about reasoning in terms of compiler phases when you have to process something that apparently may not immediately look like a programming language.
Earlier quoted context omitted.
Implementing a small domain-specific language is fairly easy. Why avoid it?
Because if it succedds, it needs to be supported long term. If you're doing that inhouse, chances are slim of original designers staying 10-20 years at the same company. Then what you have in your hands is a legacy monolith neglected over its life which might double as core of your stack and it's awful to move away from down the line. Been there, don't recommend it.
Earlier quoted context omitted.
Implementing a small domain-specific language is fairly easy. Why avoid it?
Because if it succedds, it needs to be supported long term. If you're doing that inhouse, chances are slim of original designers staying 10-20 years at the same company. Then what you have in your hands is a legacy monolith neglected over its life which might double as core of your stack and it's awful to move away from down the line. Been there, don't recommend it.
Unfortunately, that's rather true of all software.
I feel like you can apply the same sentiment to many of the "big scary things" in programming. Things that you don't want to build (as far as "common engineering wisdom" is to be believed): - a compiler - a programming language (not sure that there is a difference to compiler as stated in the article) - a database (query engine) - a CMS - a ERP But sometimes you actually _do_ want to build that (even if every alarm b…
> …But sometimes you actually _do_ want to build that… That’s not true for everyone. I’ve been a dev for 20 years and have never done any of those, and I have no desire to at all. That is ok! Programming isn’t some kind of progression to run from “n00b hello world” to “1337 compiler hax0r”, it’s a tool to solve problems with. Many of us will never have to solve these problems or have no interest in these problems. So…
The trick is to recognize that point before you have a giant, unmanageable ball of ....
Earlier quoted context omitted.
Because if it succedds, it needs to be supported long term. If you're doing that inhouse, chances are slim of original designers staying 10-20 years at the same company. Then what you have in your hands is a legacy monolith neglected over its life which might double as core of your stack and it's awful to move away from down the line. Been there, don't recommend it.
In my experience it's fine if you keep its scope limited. The scripting language for an MMO I worked on for example is simple and effective.
Earlier quoted context omitted.
I should have been clearer: written partially in C or Fortran. SBCL, for example, has C bindings in the /runtime subdirectory.
> SBCL, for example, has C bindings in the /runtime subdirectory. So nothing to do with SBCL's compiler (which is somewhat confusingly named 'Python' and written entirely in Lisp), then.
The point is that these domains have a tendency to eventually overlap each other.