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

A perfectable programming language

alok.github.io

Post reply on HN
Print view View original

121–130 of 152 posts

Re: A perfectable programming language

#121

Post by lelanthran »

SAI_Peregrinus wrote: post #91
lelanthran wrote: post #49

Earlier quoted context omitted.

> > languages without types tend to grow them, like PHP in 7.4 and Python type annotations ... > Not everyone shares that opinion. See ruby. All programming languages that have values (i.e. all of them) have types, because you cannot have a concrete value that doesn't have a type. This includes Ruby. The only difference is whether the language lets you annotate the source code with the expected type of each value. Th…

Some languages have only a single type, e.g. BrainFuck only has "byte". Shells tend to only have "string" as a fundamental type, and some helpers to do things like split strings on a separator & iterate over the elements or to treat strings as numbers to do arithmetic. Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to…

> Such single-type languages tend to be esoteric and/or difficult to program in, since every sort of data manipulation not supported by that type has to be done at runtime, by the programmer.

It depends; I recall programming in Tcl in the late 90s, and that has only the string and the list as datatypes, but it felt very powerful, like Lisp but without the easy syntax.

Re: A perfectable programming language

#122

Post by zero_shift »

travisgriggs wrote: post #10

Fortran, Basic, APL, Beta, Odin, Self, C, C++, Objective-C, C#, C--, D, Scheme, Clojure, F-Script, Eiffel, COBOL, Ocaml, Haskell, Snobol, Crystal, Forth, Python, Lisp, Brainfuck, Java, Oak, Javascript, TypeScript, Wasm, Logo, Elang, Elixir, Gleam, Elm, Zig, m4, Tcl, Simula, Smalltalk Fun challenge. Unlike the author, I have nothing really to add. I just wanted to say that "I did NOT write it with ..."

C--! I forgot that one. The ILR for the first versions of the Glasgow Haskell Compiler

Re: A perfectable programming language

#123

Post by lelanthran »

jerf wrote: post #95
lelanthran wrote: post #49

Earlier quoted context omitted.

> > languages without types tend to grow them, like PHP in 7.4 and Python type annotations ... > Not everyone shares that opinion. See ruby. All programming languages that have values (i.e. all of them) have types, because you cannot have a concrete value that doesn't have a type. This includes Ruby. The only difference is whether the language lets you annotate the source code with the expected type of each value. Th…

I also add the observation that while the dynamic typing languages are all growing in the direction of the statically-typed languages, no statically-typed language (that I know of) is adding a lot of dynamically-typed features. If anything the static languages trend towards more static typing. Which doesn't mean the optimum is necessarily "100% in the direction of static typing", the costs of more static typing do ev…

> I kind of think there's room for a new dynamically-typed language that is designed around being fast to execute and doesn't cost such a huge performance multiple right off the top, and starts from day 1 to be multi-thread capable, but on the whole the trend is clearly in the direction of static typing.

Other than the "new" qualifier, Lisp supports all of that - SBCL compiles to native code, ecl/gcl compile to C (IIRC), etc.

Re: A perfectable programming language

#124

Post by noLemming »

harperlee wrote: post #114
iLemming wrote: post #87

Earlier quoted context omitted.

> you end up with an unproductive culture Practical Lispers would like to have a word - I've been witnessing extreme productivity on some teams. Modern Lisp dialects (Clojure and likes) largely broke library fragmentation and the "not invented here" tendency that were causing real tensions in Common Lisp. You realize that "The Lisp Curse" isn't some paper, survey or objective reflection? It's just someone's essay bac…

I mostly program with clojure. I'd love that I could agree with you. For clarity I was not meaning a culture of improductivity (but it also applies), and more of a trait of the culture that is improductive, choosing to focus productivity on the wrong goals, such as reinventing everything to do it "better", "more data-driven", "decomplected", etc. > You can take it word-by-word and apply to say Javascript, and it woul…

I think you're confusing newcomers landscape of "which library do I pick", (which is real) with stretched evidence for fundamentally fragmented ecosystem.

Let's walk through your examples:

SQL libraries: Korma is dead, YeSQL is dead, HugSQL is in maintenance mode. The community converged on next.jdbc + HoneySQL. That's not fragmentation - that's exploration followed by selection.

Build tools: Boot had its moment, it's essentially gone. Leiningen is still around but new projects overwhelmingly use deps.edn. That's not fragmentation either - it's a transition, and a remarkably clean one.

Spec vs. Schema vs. Malli is the most interesting case because the convergence is still in progress. Schema is effectively in maintenance mode. Spec has stalled (spec2 never really shipped). Malli is clearly gaining momentum as the community choice for new work, largely because it treats schemas as data — which is very Clojure. But even here, these aren't competing implementations of the same thing the way, say, Javascript build tools are. They have meaningfully different design philosophies, and the community is converging on the one that best fits Clojure's values.

Compare it to JS, where we have Webpack, Vite, esbuild, Parcel, Rollup, Turbopack, and the "winner" changes every 18 months. Or Python's packaging story - pip, pipenv, poetry, conda, PDM, uv - which is still a mess after decades with a vastly larger community. Fragmentation in large ecosystems often doesn't self-correct because there's enough mass to sustain competing approaches indefinitely.

The small community size that you frame as a weakness is actually why the self-correction works. There aren't enough people to sustain five competing SQL libraries, so the best one wins and everyone moves on. The tight community, the shared values around simplicity and data orientation, and the fact that people actually talk to each other - these create selection pressure that larger, more diffuse ecosystems lack.

The productivity gains aren't speculatory - from the most pragmatic angles, I see time and again - they are real and palpable.

Re: A perfectable programming language

#125

Post by noLemming »

pydry wrote: post #100
iLemming wrote: post #87

Earlier quoted context omitted.

> you end up with an unproductive culture Practical Lispers would like to have a word - I've been witnessing extreme productivity on some teams. Modern Lisp dialects (Clojure and likes) largely broke library fragmentation and the "not invented here" tendency that were causing real tensions in Common Lisp. You realize that "The Lisp Curse" isn't some paper, survey or objective reflection? It's just someone's essay bac…

>You realize that "The Lisp Curse" isn't some paper, survey or objective reflection? It's just someone's essay back from 2011 - an opinion. It's also the deficit of code we actually use day to day that is actually written in lisp. I file it under the same heading as haskell - a language that clearly has useful ideas , but...

What a thought-terminating cliché. It sounds reasonable while saying nothing. "Useful ideas, but..." what? "But it's not popular"? Neither was Python before it become one. But it doesn't have a big ecosystem? You're describing a consequence of adoption and presenting it as a cause.

Like I said: Clojure runs significant chunks of Walmart's infrastructure, Nubank's entire banking stack serving several hundred million customers - for a second, Nubank is the biggest digital bank in the world; Apple uses it; Cisco uses it. Emacs Lisp runs one of the most enduring pieces of software in computing history. You you ever used Grammarly - it's powered on Lisp; This very site runs on Lisp.

"I don't encounter Lisp in my work and that feels meaningful to me" (there's no other way to interpret your words) is just another, personal opinion that has no practical, objective angle. "The Curse of Lisp" opinion, at least back in the day had some objective relevance that no longer holds true.

Re: A perfectable programming language

#126

Post by noLemming »

DonaldPShimoda wrote: post #117
kleiba2 wrote: post #40

> because it's perfectable. it's not perfect, but it is perfectable. you can write down properties about Lean, in Lean. Homoiconicity anyone? Lisp is one of the oldest high-level programming languages, and it's still around.

Hm. Homoiconicity is not a well-defined term (see, for example, Shriram Krishnamurthi's thoughts [0][1]), but even skimming over that fact, it is a syntactic property, while the quoted line is about semantics . Switching your language to Lisp (or one of its descendents) doesn't gain you anything semantically. [0] Shriram is an original member of the Racket project, so he's been working in the Lisp-like domain for at…

Well, okay Shriram said the term "homoiconicity" is fuzzy, but the underlying thing (the language of data and the language of programs being the same representation) is real and worth taking seriously. Citing him to wave away the whole concept is pretty wild misuse of the citation. They are refining the claim, not negating it.

> doesn't gain anything semantically

Syntactic properties create semantic affordances. The reason "code as data" matters isn't that the parentheses look a certain way - it's that the AST is a first-class citizen of the runtime data model. Those are semantic capabilities - they determine what programs can express and compute, especially at the meta level. The syntactic uniformity is the mechanism; the ability to write programs that construct and transform other programs, using the same tools as everything else, is the payoff.

Homoiconicity doesn't make Lisp programs mean something different, but it gives you a more uniform and powerful meta-programming model.

Re: A perfectable programming language

#127

Post by matt_kantor »

tadfisher wrote: post #115
matt_kantor wrote: post #96

Earlier quoted context omitted.

> 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 Kot…

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.

Re: A perfectable programming language

#128

Post by miniBill »

zero_shift wrote: post #120

> at a party, Sydney Von Arx asked if i could name 40 programming languages. An attempt (without looking) JavaScript QBasic PHP Haskell C C++ Ada Algol Racket Scheme Clojure Common-Lisp GOOL Fortran Awk Postscript Forth C# F# Lua Java D Odin Rust Zig Julia Python Nim MATLAB Bash Brainfuck Arnold-C Intercal Gleam Unison Ruby Crystal Erlang Go TCL Phew!

It's a fun challenge! My list is Ada Agda Assembly Awk BASIC Brainfuck C C# C++ COBOL Curry D Elixir Elm F# FORTRAN Gleam GLSL Go Haskell HCL Idris Intercal Java Javascript Objective-C Ocaml Pascal Pony Prolog Python R Ruby Rust Sh Sketch Swift Typescript Visual Basic Zig

Re: A perfectable programming language

#130

Post by speed_spread »

nobleach wrote: post #59

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,…

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