5 ms·
Disclaimer : I'm just some moron on the Internet Unpopular opinion: I hate meta programming. We have composition, why do you need to mess with the nature of th
by jrq 8y ago
Disclaimer : I'm just some moron on the Internet
Unpopular opinion: I hate meta programming. We have composition, why do you need to mess with the nature of things? A long time ago, I was freelancing Rails. I can't accurately describe the deflating feeling of tracing your problem back to some class that one person (a ruby guru warrior, no doubt) wrote, with a few dozen dynamic deeds or to_methods. It's the most demotivating thing I've come across in real life code.
It's worse somehow than complicated numeric code, because with the numbers, at least I know this shit works by the end of it. If I start writing good var names, I'll probably even figure out how it works in an hour or two
That being said, I'm tentatively excited about Tasty. What a witty name by the way!
Having the extra type information should allow for much smarter transforms at the language level and I hope macros in scala 3 aren't so much a mess.
Also, let's just get rid of implicits, whaddaya say? ;-)
Anyways, proud of the scala 3 team this far. Even though they haven't killed sbt yet, they're putting their work in admirably to a difficult problem. I'd love to have that much meaning and purpose in my own work.
I didn't have time to actually read spec, will do later, so if I said something inaccurate, let me know gently
Edit: macros will conform to black box and be constrained to their types, runs after type checking.
That's awesome
- papaf 8y agoI hate meta programming. We have composition, why do you need to mess with the nature of things? Maybe you just hate bad metaprogramming? In theory metaprogramming makes a language more powerful, leads to less boilerplate code, and can deliver big performance improvements. Scala gives programmers plenty of power which comes with the tradeoffs that there is plenty of opportunity to shoot yourself in the foot or produce unmaintainable code. Scala makes different tradeoffs to Go. Personally, I think that ignoring metaprogramming means missing out on one of the most powerful techniques available to programmers.
- cbzbc 8y agoMaybe you just hate bad metaprogramming Metaprogramming is hard to get right - often harder than writing good libraries, and the number of programmers who can do it well is correspondingly smaller. So of the metaprogramming that's out there in the wild, a correspondingly greater proportion of it is bad.
- hardlianotion 8y agoLi Haoyi shared his alternative to sbt here a little while ago. Looks good to me. http://www.lihaoyi.com/mill/ http://www.lihaoyi.com/mill/
- jrq 8y agoI've seen it a while ago too, but without lightbend blessing it's next to useless, in practical usage. I can't deliver that to a client
- walkingolof 8y agoThere is more to it, sbt has a very rich echo system of plugins, it will take time for any alternative to gain traction.
- jrq 8y agoOf course, I agree. In time, as the scala ecosystem flourishes and adapts, I, along with many others, may be coaxed back in. Scala suffers from a problem of too many bright people all trying to solve too few problems. And implicits. Bad idea there. But the rest of it is logistical, and just takes time, as you said. Have faith! Learn ocaml or f# too, but have faith all the same.
- threeseed 8y ago> Scala suffers from a problem of too many bright people all trying to solve too few problems 1000x yes. And bright people who are so bright that they simply can't appreciate what the user experience is for people who aren't bright. These people are from a lot of experience a bit toxic. And it's a bad choice of word and it isn't personal but because they are on a different level technically they can really change teams for the worse. At some point Scala is going to need to better reconcile the Typelevel world of Scala and the Play/Java world of Scala. Otherwise languages like Kotlin is going to chip away until nothing is left.
- aphexairlines 8y ago
- rauhl 8y ago> Unpopular opinion: I hate meta programming. As papaf asked, is it metaprogramming you hate, or bad metaprogramming? Metaprogramming is just another tool in the toolbox, and hating syntactic abstraction (macros) makes as much sense to me as hating procedural abstraction (functions). Yes, it’s easy to write bad syntactic abstractions, but it’s also very easy to write hilariously bad procedural abstractions, too. cbzbc states that metaprogramming is often harder to get write than functions. I’m not certain that’s true; might it just not be the case that most programmers just don’t get very much experience with metaprogramming, since they’re typically using languages with very underdeveloped facilities for it? > A long time ago, I was freelancing Rails. I can't accurately describe the deflating feeling of tracing your problem back to some class that one person (a ruby guru warrior, no doubt) wrote, with a few dozen dynamic deeds or to_methods. It's the most demotivating thing I've come across in real life code. My own experience is that for some reason Ruby tends to attract programmers who enjoy doing things because they can be done, not because they should be. It’s so bad that my general rule is not to use systems programmed in Ruby, because I’ve been burnt so many times before. That’s not entirely fair (obviously there are some great systems written in Ruby — e.g. I believe that both GitHub & GitLab are), but it reflects my experience.
- rtpg 8y ago> hating syntactic abstraction (macros) makes as much sense to me as hating procedural abstraction (functions). This is a bit pedantic, but... Many people's experiences with macros are through C. C macros are not syntactic abstraction, but some sort of lexical expansion that introduced syntactic confusion. I get this is not the case in many languages now but for most popular languages macros are "throw appended strings into eval/C preprocessors"
- hellofunk 8y ago> Unpopular opinion: I hate meta programming Come to the dark side and start programming Clojure. Because there, meta programming is no different than regular programming -- your macros are just normal Clojure functions that happen to run at compile time, and they have the full language to do whatever you want.
- moomin 8y agoEven in Clojure, you probably shouldn’t if there’s an alternative. Full disclosure: I have written useful Clojure macros.
- hellofunk 8y agoFunctions are ultimately more powerful since you can store them, pass them to other functions, partially apply them, etc. You can't do that with macros, of course. But macros allow very repetitive stuff to be automated which is a real productivity win.
- jrq 8y agoBut there's no types! I've never tried clojure, but I've done scheme before. Maybe I should... Thanks!
- norswap 8y agoRule 1 of metaprogramming: don't use it when something else will do (almost) as well. Still, I think there is a need. Take declarative DSLs for instance. The problem with how that's done in all languages right now is that these DSL are running code that build a tree model of sorts. In some languages like Java or C# that's already ugly because the code must live in an variable initializer or method of a class somewhere (why couldn't it be it's own thing?). Another problem: how to "refer" to a different part of your model? Solution 1: pass bits of trees around. So you need to store them in variables. In almost all languages this precludes forward references and circular structures. Solution 2: use strings, with all the safety and performance issues that does entail. Then you have to realize the model is not first-class, it's just a data structure being built. So you can't generate useful methods based on it - you need to have generic functions that take your model as input and interpret it on the fly. There are many many more use cases, but this one is the one that irks me the most. Why the hell do I need sinful XML, Groovy or what not to compile my Java project. Heck, even make. With some decent (compile-time!) meta-programming support, I could have all this as a DSL with all the might of the language tooling (autocompletion, IDEs etc) to bear.