sklogic

23 ms·

181.
by sklogic 10y ago
Pay attention to what you're answering to. It was you who moved the goal posts. > there are well known techniques for eliminating any complexity you can find in a chain of compiler transforms , Can you imagine finding a working ter
182.
by sklogic 10y ago
It's only a problem if your tools are done the wrong way. The proper tools can benefit from the macros instead. Of course, some discipline in how macros are implemented is required.
183.
by sklogic 10y ago
Now you're talking about an infinite complexity. It cannot be reduced no matter how hard you try. It has nothing to do with the kind of complexity that software engineering have to deal with. But, for all things practical , yes, it&#x
184.
by sklogic 10y ago
The kind of complexity that is important for software engineering is defined by the size of the atomic modules you can get (those that cannot be broken down any further and still be practical) and number of dependencies between such modules
185.
by sklogic 10y ago
Are we talking about optimisations now? Or still about a compilation ? Optimisations are a totally different story. They can bring some complexity in, but the nice part is that they're totally optional and not required for solving
186.
by sklogic 10y ago
> Honestly, I don't get the fuss about macros. DSLs are an ultimate solution. And DSLs are best implemented with macros. > where they don't make the code harder to understand Macros are there to make code easier to underst
187.
by sklogic 10y ago
> No. Why would you say so? There is nothing simpler than compilers. They can be broken down into pieces as small as you like which are still independent and fully sequential. Most of the rewrites you'll ever need to do can be done
188.
by sklogic 10y ago
> helps to reduce incidental complexity to some extent This extend stays untapped. You cannot even imagine how far this ability to eliminate complexity extends. Of course, it's not just Lisp, it's Lisp (or any other meta-langua
189.
by sklogic 10y ago
I don't even remember when was the last time I saw eval being used outside of the macros. And the latter is also quite a specific and rare use case.
190.
by sklogic 10y ago
You can have both a flexibility of DSLs and strict rule enforcement. Just write a restricted DSL.
191.
by sklogic 10y ago
By "fixing", I suppose, they meant "to eliminate the known evil that rooted deeply in the software world, such as unsafe languages, unexpressive boilerplate languages, and so on". Making sure the evil is dead for good wo
192.
by sklogic 10y ago
Norvig nailed it - instead of being sissy about macros altogether the mainstream languages must rather enforce a certain discipline. And the rules for the macros done right are very simple and well known.
193.
by sklogic 10y ago
I did it many times elsewhere in this thread already. For example, this one: http://www.moserware.com/2008/04/towards-moores-law-software... Or Nanopass itself, not just as a tool for building DSLs, but as an exam
194.
by sklogic 10y ago
> These are functions, it doesn't get any simpler than that Simplicity of the building blocks does not affect complexity of the resulting mess of code. Look, Brainfuck have only 8 operators. It cannot get much simpler than that.
195.
by sklogic 10y ago
P.S.: and the free monad part is not what I'm calling convoluted and unmaintainable. It's ok to assemble an AST this way (yet, a custom parser is better). The problem here is in the interpreter part. Interpreters are inherently
196.
by sklogic 10y ago
> you're underestimating the difficulty of creating a good DSL way too much. I'm doing this for living, and I can't stop wondering at how laughably easy it is. The method is very simple: * describe the problem in plain En
197.
by sklogic 10y ago
(cannot answer there too, weird...) No, I conculded that you have no idea how to implement macro-based DSLs from your remarks about composability and debugging. You cannot be so out of touch and still know something about the macros. And, n
198.
by sklogic 10y ago
Why would you be interested in my pitiful attempts if even the best examples of the monadic DSLs people keep pointing too are all thoroughly horrible, convoluted and unmaintainable? Likewise, why should I look at your macros if you already
199.
by sklogic 10y ago
And in a lisp you'd be able to mix Haskell and Prolog together, with dozens of other languages as well, seamlessly and efficiently (unlike the non-destructive Prologs people tend to embed in Haskell).
200.
by sklogic 10y ago
Even Datalog can be extremely useful: http://www.cs.cmu.edu/~aldrich/courses/654/tools/bierhoff-bd... Also take a look at this, quite a convincing example of how useful Prolog can be in a compiler pipeli
201.
by sklogic 10y ago
This is not an answer to my question. What are you proposing instead of macros?
202.
by sklogic 10y ago
Monadic interpreters? Composable? Are you kidding? It is a joke, not a composability. You cannot take a type system of one DSL, modules from another and only the expressions syntax from a third one and then mix them all together into a new
203.
by sklogic 10y ago
No, this has nothing to do with anything simple. It is awfully overengineered. It is definitely not a way do implement DSLs.
204.
by sklogic 10y ago
I think that it can at least be a sign of a good design. If it went that far and still kicking, chances are pretty high. Any comments on any other points I made?
205.
by sklogic 10y ago
> There is much that can be done with regular, bog-standard functions. You cannot implement simple, modular, debuggable, composable DSLs with functions alone. And you cannot tackle complexity without DSLs. > Yes, macros can be useful
206.
by sklogic 10y ago
Tagged memory was definitely a way to go. Would have eliminated most of the security issues we had so far. Luckily, it's slowly making a comeback, see the RISC-V efforts for example.
207.
by sklogic 10y ago
> Why is it so hard to see that this can lead to an explosion of unreadable code if left unchecked? Anything can lead to an explosion of unreadable code if left unchecked. Any language feature, with no exceptions. Variables, loops, funct
208.
by sklogic 10y ago
> How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? That's exactly what's wrong with this thoroughly broken industry. They should not have learned this awful religi
209.
by sklogic 10y ago
> In my experience, most people who are so in love with macros/DSL's work on solo projects. Yes, but not because it's hard to cooperate when you use DSLs (it's in fact far easier to work in a team this way). It's
210.
by sklogic 10y ago
Mind naming a single one? I do not believe such a thing exist. Macros are the ultimate solution.

More ›