Well, it would just require the person building the type-system to write a parser himself and it would need to be a extra step in your compilation pipeline. It would be like a linter.
I have jet to see compiler hooks that are as simple as to write as they are in lisp. Also, most of them are far less powerful then they are in clojure.
I see tons and tons of example were people use clojure macros in intressting ways but not that many people who write scala compiler hooks.
So in theroy you are right, in practice I have not jet seen tons of examples.
Many (probably most?) of them don't, but I don't know that it has much to do with the syntax. And many do. GCC has a plugin infrastructure, and Clang is well known for having a better one.
Clojure has a lot of great things going for it. I don't have any objection to Lisp syntax - I like it although I don't know that I prefer it - but I don't think we should be crediting it with things more properly deserved by other pieces. Proper support for macros is a biggie.
> Many (probably most?) of them don't, but I don't know that it has much to do with the syntax.
It has to do with the syntax. Working Lisp "plugins" is very simple because all the code is represented as plain datastructures. Rewriting program is like writing simple data structures manipulation code.
The same is true for any AST. The datastructures get marginally more complicated, but that's rarely the limiting factor.
Strictly speaking, AST data structures are often full of junk, but that's not mostly a matter of the complexity of the syntax itself but of the variety of things being done with that AST - you can't report error locations if all you have is the nested lists representing your Lisp program.
The focus on making macros work well is absolutely a strength of Lisps. The syntax is a much smaller part of that than the lore would suggest.
I agree with you generally it is possible with other langauges but to really do it is quite hard. As of right now I will stick with Clojure compared to the alternatives. I also really like working in rust and I have found use for macros there too.
More syntax makes things harder, compiler that have not been designed wit this goal make things harder. You can look at the papers trying to get this stuff in to other langauges and there are some problems, dylan [1] was doing it befor most others, now rust is coping that stuff.
Actually some of the coolest stuff was done by David Moon (Common Lisp, Dylan) he greated a langauge spec that he calls PLOT [2] and it has a very inovate macro system. For anybody that is intrested in that sort of stuff I highly recommand it.
More syntax makes things harder, but the amount of hardness introduced by the craziest syntax is dwarfed by the rest of hardness involved in introducing a type system. It's like saying "Steve was able to walk 20 miles, because his driveway slopes down a little". It may be true that his driveway slopes down, and that may make that stretch easier, but other things are more important.
Its no different in any other language with macros, the data structures are just bigger. It's pretty easy to write a Rust macro or Scala macro that consists of simple data structure manipulation. I have a simple example here: https://github.com/jroesch/pg-typeprovider/blob/master/src/t....
No not really. Optional type annotations are not the same thing as optional typing. F# is strongly and statically typed and if you expect it to be something else you will be frustrated.
You are correct, but I would claim that the type hinting in F# combined with pattern matching over algebraic datatypes makes dealing with a static type zoo much more enjoyable than in some other languages.
Both languages are very similar in way that they support lists, arrays and maps as first class citizens as fundamental types and provide expressive algorithms to operate over them 'out of the box' with more or less uniform syntax.
To me, as a novice, the main apparent practical difference between the two languages are the domains for which there is strong support and which have discoverable solutions. I.e. the platform and the community.
Hy looks really incredible, because it's like Clojure without the JVM. I really hope it becomes more popular. It might take a ClojureScript variant to compete, though.
If anybody on Arch Linux wants to give a Hy a try, I put together a PKGBUILD: python-hy.
I'm experimenting on this with Hype. It's barebones and does some whacky-don't-look-at-it macro "magic", but it works! Also trying to mimic core.typed's way of annotation.
Note: Just using python functions annotations with a typeannotation library to provide some runtime type checking. It's rather rad if i can say so my self.
From sources... Amazon is a heavy Java -> Scala shop. They are probably looking at Clojure to diversify as Scala is hitting some growing pains, but they can still leverage their large JVM expertise.
From sources... There's not much overlap between the Scala and Clojure folk, so nothing to do with any "growing pains". Scala's seeing much more uptake than Clojure.
Yeah, I can't imagine someone who's proficient with Scala seeing anything special in Clojure. I'm just a sight-seer in those languages, but I can see there are some neat things in both.
Parenthesis are always offputting to me, even though I like a fair amount of clojure concepts. I often feel like functional programming has made a cottage industry around putting obfuscated names around relatively simple ideas (see transducers for example)
Amazon actually has a pretty interesting history with Lisp. I believe Steve Yegge has written about it before, but I'm not sure. It was pretty much completely gone by the time I got there though. Amazon went from almost completely C++/Lisp to almost completely Java/Ruby over the course of about 5 years.
I'm not directly in the dev space, but it appears as though the choice of languages that people use has far more to do with what Builder Tools will support than what people actually want to use. Teams only use Scala or Clojure if they are willing to build it using their convoluted Ant wrapper that doesn't make any sense.
I was really into Scala and studying it and everything. I still remember all the scala bloggers I follow, Daniel, Tim MOrris, Paul Snively, etc...
Eventually I landed into a scala job role. Oh boy was it different. The other programmers were like type casting to Any or whatever that generalize highest type was (unified type theory).
The complexity is pretty high, it's great if you know it all but in all seriousness it was impeding...
That's just bad usage of a language feature don't you think. I'm still trying to figure out whether to blame the language because of the way programmers use it.
Personally, I like the object + static typing + first class functions as it eliminates 90% of errors at compile time. If any error occurs at run time, am pretty sure it's logical. This is a huge plus. The only drawback - the ridiculous amount of type specific code you have to write for mundane changes/updates.
Scala with mediocre programmers (CommodityScrumDrones writing FactoryVisitor classes) is an outright disaster.
The Java community has its flaws (oh boy, does it) but it has adapted to the hordes of mediocrities. Give Scala to mediocre engineers (who typecast to Any, use null instead of Option[T]) and you have the Java hell with worse IDE support and 5x compile times.
Amazon is literally thousands of shops with a libertarian CEO. The fastest way to end a career there is to try to force a company-wide standard language although many have tried and failed.
I wouldn't be surprised if Clojure has more "industry" adoption than Scala at this point.
Give me Clojure semantics (anti-OO, maps, vectors, and seqs) with some optional typing and a Python syntax then I'm there *
* that's just my preference, no need to convince me of anything other.