Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Janet: a lightweight, expressive and modern Lisp

janet-lang.org

Post reply on HN
Print view View original

201–210 of 280 posts

Re: Janet: a lightweight, expressive and modern Lisp

#201

Post by jbeam »

orthoxerox wrote: post #141
moron4hire wrote: post #105

Earlier quoted context omitted.

Microsoft doesn't make breaking changes. I have code that has survived three or four of your supposed cycles that still runs completely fine.

Microsoft did kill off or sunset some parts of the Framework. WCF, WWF, AppDomain, expression trees, dynamic, VB. People who wrote WCF services in VB for a living are probably extremely disappointed.

Do you have anything to support that expression trees are being sunset? I haven't seen anything of the sort, unless you are talking about a deprecated library that has been replaced. But System.Linq.Expressions is still around.

Re: Janet: a lightweight, expressive and modern Lisp

#202

Post by didibus »

kleiba wrote: post #23

Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…

In that respect, Janet doesn't really bring anything very new. Its just an alternative to Lua. Truth is, Lua had pretty few alternative as it stands. When you need something small, fast, to embedd. So Janet is a competitor there.

Re: Janet: a lightweight, expressive and modern Lisp

#203

Post by didibus »

roenxi wrote: post #134
adamkl wrote: post #111

Earlier quoted context omitted.

I agree that it doesn't have to be a trade-off, but that mindset might explain why there is less focus on creating one-click installers. An example would be Clojure's newish approach to managing projects via the CLI and deps.edn. It's very powerful, and expressive, but definitely not a one-click approach.

Clojure is an inspirational language that has some insightful opinions about how things should be done. A month spent learning Clojure is a great investment. A lifetime programming in Clojure would be a joy. But as I recall the original Rich Hickey talks on "Why Clojure?" he was explicit that dependency/project management were very hard problems that Clojure didn't really attempt to solve. I'm not aware of any Clojur…

> I'm not aware of any Clojure tools that are best-of-breed for project management. Java has a better model for locking everything down (or maybe how the Linux Distros manage their repositories)

Uh? Clojure locks everything down as a well. In fact, deps.edn solves many issues experienced with Maven.

Personally, I've found Clojure dependency management to be the best I've ever used in any language. It's simple, explicit, gets out of your way, and lets you just do your work.

> and Python has a better model for just keeping up with the current state of things.

I'd like to hear about this? Pip doesn't even have a command to update all dependencies in one go. And figuring what even are the dependencies of any given project is a mess.

Re: Janet: a lightweight, expressive and modern Lisp

#204

Post by moron4hire »

jbeam wrote: post #201
orthoxerox wrote: post #141

Earlier quoted context omitted.

Microsoft did kill off or sunset some parts of the Framework. WCF, WWF, AppDomain, expression trees, dynamic, VB. People who wrote WCF services in VB for a living are probably extremely disappointed.

Do you have anything to support that expression trees are being sunset? I haven't seen anything of the sort, unless you are talking about a deprecated library that has been replaced. But System.Linq.Expressions is still around.

I've also seen nothing about DLR being removed

Re: Janet: a lightweight, expressive and modern Lisp

#205

Post by fnord77 »

blandflakes wrote: post #110
kleiba wrote: post #23

Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…

On the VM front, I love the JVM, but a vast majority of languages gaining popularity are generating static binaries. GraalVM may help close the gap here. OO is overrated but most apps have some state and I found the entity-component systems solid but not still unwieldy. Clojure has really great concurrency primitives; all the semantics I could want built right in. Except my concurrency often occurs in the persistence…

I think we'll see a flip back to VMs once we start seeing a variety of architectures in production - ARM, intel, risc-v.

Managing distributions for a bunch of different architectures is difficult.

Re: Janet: a lightweight, expressive and modern Lisp

#206

Post by blandflakes »

fnord77 wrote: post #205
blandflakes wrote: post #110

Earlier quoted context omitted.

On the VM front, I love the JVM, but a vast majority of languages gaining popularity are generating static binaries. GraalVM may help close the gap here. OO is overrated but most apps have some state and I found the entity-component systems solid but not still unwieldy. Clojure has really great concurrency primitives; all the semantics I could want built right in. Except my concurrency often occurs in the persistence…

I think we'll see a flip back to VMs once we start seeing a variety of architectures in production - ARM, intel, risc-v. Managing distributions for a bunch of different architectures is difficult.

That would be interesting, though I wonder whether containers will (sadly) be the answer there.

Re: Janet: a lightweight, expressive and modern Lisp

#207

Post by doteka »

microcolonel wrote: post #193
roenxi wrote: post #169

Earlier quoted context omitted.

> For what it's worth, having used Clojure for work for a couple years now... > ...it makes perfect sense to me that they are separate... > A lib’s container is a Java resource whose classpath-relative path is derived from the lib name [0] > No matter what some people say, getting started in Clojure is a nightmare. ~ galfarragem (earlier in the thread). I'm hoping this smorgasbord of quotes is making my point for me…

No, these are not making your point for you. You bring up :import and :use, but in truth, a beginner or intermediate Clojure user is not going to use either of them at all; and when they choose to, it'll be because they have some deeper knowledge which will make the documentation appropriate to them. :import is primarily for people who understand Java and the JVM. If you know what you're importing, you will understan…

And people wondered why Clojure is dying...

Somehow a language designed from scratch with all the purported wisdom of Lisp ended up with a nastier import solution than JavaScript, which had none out of the box for its first two decades of life, and then had to reconcile as many as 5 different module systems.

Re: Janet: a lightweight, expressive and modern Lisp

#208

Post by fnord77 »

varjag wrote: post #34
kleiba wrote: post #23

Okay, so when Clojure came along, it came with a strong underlying philosophy of what the language was supposed to be/do. Among them were design decisions such as, e.g.,: - VMs, not OSes, are the platforms of the future, so target the JVM - Object Orientation is overrated, but polymorphism is a good thing - Multi-core is here to stay, so use immutable data structures to greatly facilitate writing correct concurrent p…

The first point clearly didn't pan out. In reality, applications ended up bundling their own OSes along, so Clojure is stuck with antiquated VM on its ankle for no good reason.

we'll see a renewed interest in VMs once diverse CPU architecture becomes more common. ARM and risc-V servers and laptops are coming.

right now if you release binary software for linux, windows and mac, you basically have 3 versions to distribute.

that will turn into 9 versions per release. that's a build and release nightmare.

Re: Janet: a lightweight, expressive and modern Lisp

#209

Post by zentiggr »

anonymoushn wrote: post #84
HelloNurse wrote: post #65

Earlier quoted context omitted.

In other words, on the first day day of testing under realistic load conditions you learned how to measure GC pauses; then, presumably, you were able to improve performance. It shouldn't have happened in a production environment, but setting up a way to lose tens of thousands of dollars if performance is bad, trusting unreasonable numbers, trying to produce no garbage, and requiring no GC pauses because margins are t…

Right, we improved the performance by moving the work out of the JVM. It's my fault that if you trade US equities based on old information you lose money? Edit: Actually, I'm still not sure how to correctly measure GC pauses, other than from inside the application.

I'm not sure I've ever heard of the JVM being used in trading level software before. I've gotten a broad but vague impression that custom applications are the norm.

No criticism, as I've only read others' accounts, but that sounds out of character.

Re: Janet: a lightweight, expressive and modern Lisp

#210

Post by egl2020 »

mhd wrote: post #46
oblio wrote: post #26

Earlier quoted context omitted.

It's not really something new. Ada ( https://en.wikipedia.org/wiki/Ada_(programming_language) ) was created 40 years ago. Kids with crazy names is a long standing tradition, going back millenia :-)

Also Amos, Haskell, Idris, Joy, Miranda or Yorick. Arguably Dylan or Pascal. I'm more confused by a name starting with a capital "J" not being associated with Java, as once was custom. As for kid's names, definitely[1]. [1]: https://www.youtube.com/watch?v=Jg9w0YSMLHY

"associated with Java, as once was the custom". Like JavaScript. Yeah, right.
Post reply on HN