Hacker Newsnew | past | comments | ask | show | jobs | submit | nobleach's commentslogin

The perfect programming language has:

  - The compile speed of Go
  - The performance of Go
  - The single binary compilation of Go
  - The type system of Kotlin
  - The ecosystem of JVM (packages for anything I could dream of)
  - The document sytem/tests of Elixir
  - The ability to go "unsafe" and opt for ARC instead of GC
  - The result monad/option monad and match statements from OCaml/Gleam
  - A REPL like Kotlin or even better, OCaml
  - A GREAT LSP for NeoVim
  - A package/module system that minimizes transient dependencies
  - No reliance on a VM like BEAM or JVM
I still dream about this "one size fits all" language.

Common Lisp through SBCL fits this for everything but changing GC strategies. I'm not sure why you'd do that, though. SBCL's generational GC is faster in all cases, easy to reason about, and trivial to pause.

In many of these other categories, clisp exceeds requirements. The REPL and Doc situation is so good it's honestly worth it for those alone. People put up with `):'(,@ soup for good reason.


I luckily have the freedom to work with SBCL almost fulltime. It is a joy; shame most will never get to experience it (few jobs, parenthophobia etc).

Common Lisp Is exactly that. I wish I could use it at work. All my personal stuff nowadays is CL only. There is no other choice.

I believe there are tradeoffs which is why this doesn't exist. Isn't the compile speed of Go so good because it's type system is much simpler?

One thing I like about TypeScript is that there's tooling for "quickly strip out the types and give me something I can run; I don't care if it's correct". You can run the (slower) type checker concurrently with that (or whenever it's convenient to do so), but type-checking doesn't necessarily block you from being able to play with runtime stuff.

I understand that this workflow can't be realized in languages whose runtime semantics are derived from type-level stuff, and while that can be quite convenient I'm personally willing to give it up to unlock the aforementioned workflow.


"Isn't the compile speed of Go so good because it's type system is much simpler?"

That, and forgoing fancy compile-time optimization steps which can get arbitrarily expensive. You can recover some of this with profile-guided optimization, but only some and my best guess based on the numbers is that it's not much compared to a more full (but much more expensive) suite of compile-time optimizations.


Yes, programming languages are designed for a purpose and importantly for a concrete system. Erlang is the way it is because it was designed for Ericsson's phone network. C is the way it is because it was designed for the PDP-11. Logo is the way it is because is was designed for young children. Go is they way it is because it was designed by Google for Googlers.

You can't design an abstractly "perfect" programming language without any context. Which is why the author I think focuses on "perfectable", as in the language can be made perfect for your purpose but it's not going to be one size fits all.


No, I realize that. It doesn't stop me from having my "perfect language wishlist". The author calling out "perfectable" is what got me thinking. What language would I choose if I were able to "perfect" it just a bit more?

But you had called your list "one size fits all".

oh yeah absolutely. The moment you start blowing up Go with features (for example) the speed decreases dramatically.

performance of Go - why not Fortran? type system of Kotlin - why not Scala/Haskell? Repl like Kotlin, why not Clojure?

> The result monad/option monad and match statements from OCaml/Gleam

Do you mean actual monads or just the specific result/option containers? If you mean a fully-fledged monad abstraction then you need a more sophisticated type system than what Kotlin provides (i.e. higher-kinded types).


Kotlin itself has opted for inline union types to represent error results: https://github.com/Kotlin/KEEP/blob/main/proposals/KEEP-0441...

The existing Result type was a mistake to expose to users, IMO, as it encourages exceptions-as-control-flow and error type hierarchies which complicate error-handling even further. The convenient `runCatching` API also completely breaks reasonable error-handling on the JVM and Kotlin's structured concurrency (which happens to use exceptions-as-control-flow to signal coroutine cancellation).

Overall, Kotlin is moving away from higher-kinded types in the core language, not toward them.


I'm not a frequent Kotlin user but none of that surprises me. My comment was asking about nobleach's imaginary "perfect programming language", which is clearly not Kotlin.

What do you like so much about Kotlin type system, and document / testing of elixir?

"The compile speed of Go" - Delphi starts laughing

- The reach of JavaScript

The type system of Kotlin? It's the same as Java + syntactic sugar for nullability. Don't pretend otherwise.

It's always fun to realize that USENET is still out there humming along. I still remember the thrill of working on my ancient Delphi/Object Pascal projects, and posting questions... waiting a few hours and checking back for responses. There was no "instant gratification" in those days. (I wasn't really using IRC).

Opening this, and just searching "Delphi" I see that USENET never did get that "censorship" that I always assumed would eventually happen. The group names alone are truly unhinged. The Wild West is still.... wild!


the alt.devilbunnies vs alt.pave.the.earth "wars" kept me sane as a teenager. I miss the old internet.

Devilbunnies? Man, I haven't heard that name in a long long time. I used to be obsessed with reading all the stories in that universe. Never contributed anything though.

Imagine how odd it was to discover Usenet and find that someone else was already using your (offline) nickname for an entire universe of stuff. Early 90s.

It's mine here! I'll cede it to someone with the better online claim but only if you can prove you're not a Fudd in disguise.


I remember the epic flame wars with a certain game developer (who I wont name so as not to create drama here) whose starship simulator had a few bugs.

It's used for piracy a lot still.

Yup, in the 2005ish era, I found that I was downloading albums just because I could. Some I never even listened to! I got rid of my EasyNews subscription because it all seemed so silly to me.

80 miles for me! I was a Space Shuttle era kid though. Saw the Challenger disaster during my lunchtime. And then on perpetual replay for the rest of the week on WESH/WCPX/WFTV most likely. Even still, just knowing we were launching all those people into space was awe-inspiring.

TBH, I was probably closer to 80 miles than 60 before we moved. to Daytona... Flagler Beach. You?

Heh, Ormond Beach first, then Flagler - Palm Coast (FPC - go, fight, win!)

I was a poor kid building computers in the mid to late 90's. I tried everything I could NOT to use a true Pentium. My first build (coming from an upgraded Compaq 386DX) was an AMD 486 "DX4". I had a Diamond Stealth PCI VGA card and 16mb of DRAM. After that I tried a 233Mhz Cyrix 6x86. That chip was garbage. I had to run some software pentium emulation to get Cubase to run. I went 300Mhz Celeron after that. That was my first time trying the new SDRAM! After that I FINALLY got a legit Pentium III 400Mhz! I could go on and on as this is a lovely walk down memory lane and there's been some fun dips back into AMD Athlon/Ryzen/etc.


> I tried a 233Mhz Cyrix 6x86. That chip was garbage.

Those chips were excellent value for mostly integer work, but had incredibly poor floating-point performance which was a problem for gamers as the 3D era was really getting going around that time. I had one, it did me good service for a few years.


Yeah, I was all about recording music/running the first iteration of software synths. I was a Graphic Design major at that time so Photoshop/Illustrator/QuarkXpress were my jam. Those suprisingly didn't run that bad - in real Graphic Design, no one used Eyecandy (the reason everything on the web in 1998 had drop shadows, outter glows, lens flares) so rendering "3D" rarely came into play.


Not only performance, I strongly suspect there were issues with implementation too as the apps would just freeze/die frequently.


They were practically overclocked coming out of the factory, so if you had any issue at all with cooling, or attempted to clock them up even higher, they would be unstable.


"poor"


As a VERY long-time Linux user, I agree. Multi-monitor setups, where you can unplug the monitor and have your windows gather back onto your laptop screen requires WAY too much configuration. Having your audio switch back to internal laptop speakers requires homebrewing a script. On my 2020 Dell XPS, I still haven't figured out how to enable the subwoofers - so I'm stuck with ThinkPad quality audio. I have 3 ThinkPads (one with straight ArchLinux, 2 with CachyOS) and there's always some little piece I'm annoyed with. The X1C has good battery life, the T480 and P14s are meh. I JUST bought my first HiDPI Lenovo laptop this weekend. Getting that to be a decent tradeoff between readable text and mongo-duplo-massive UI has been "fun". (Yoga 15.3" Aura edition - I really like it) But running apps in Wine is darn near impossible - the text is for ants!

All of these issues go away with Mac and Windows. I'm not giving up on Linux, I'm just a realist.


>On my 2020 Dell XPS, I still haven't figured out how to enable the subwoofers

If I remember correctly dell never provided drivers/firwmare/docs upstream to drive the subwoofer. ref: https://bugzilla.kernel.org/show_bug.cgi?id=215233


Have you ever watched someone USE those COBOL TUIs? Everyone from airline ticket agents, to local governments, to folks at Home Depot while looking up inventory. They could fly through menus and accomplish things. I remember when Best Buy switched to a Windows-based experience. It was terrible. Simply adding a mouse+windowing experience slowed everything way down. I saw it first hand at Target too. They went from an OS/2-based TUI to Windows NT. I know there'll always be those folks that think we're all just trying to play "leet Haxorz", but there's just something about those systems that people deeply connected with.


While Astro does indeed have its own type of components, it also supports React, Solid and a host of others. So transplanting your current tree of components in, adding the React plugin and saying "GO" is likely a fairly straight-forward project. I moved a previous static site into an older verison of Astro with very little trouble.


What would you call a person who, when presented with new information, refuses to change their mind? Dogmatic? Religious? An Idiot? I'm sure there's some self-serving reason the guy wants to go to the moon. What we don't know is if he's had that in mind the entire time.


I convinced one boss to let me spike out a project with it. I was in love with OCaml at the time. OCaml's docs are... I'm just going to say it, they're terrible. F# on the other hand, has fantastic docs. In the end, the only real gripe I had was the significant whitespace. I'm just not a fan.


Way back when I was in IT Admin, I used to have this problem all the time. Some non-tech person emails a spreadsheet, another non-tech person edits it, and saves it. The original person complains that they can't see the changes. Yeah, because it's saved in some MS Windows Profile location that no sane human would ever visit. My solution was to ONLY email links to shared files on a shared resource. The LAST thing I'd ever think of is writing software to solve this problem!

These days if I were interviewing someone and they said, "I'd use the simple solution that is fairly ubiquitous", I'd say, "yes! you've now saved yourself tons of engineering hours - and you've saved the company eng money".


I attach a copy of the file and then provide a network location for where it is located. Makes it easy for people to just open up a simple copy to look at it and they know where to go to access the original.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: