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

91–100 of 152 posts

Re: A perfectable programming language

#91

Post by SAI_Peregrinus »

lelanthran wrote: post #49
shevy-java wrote: post #32

> languages without types tend to grow them, like PHP in 7.4 and Python type annotations Well ... that is a trend that is driven largely by people who love types. Not everyone shares that opinion. See ruby. It is very hard to try to argue with people who love types. They will always focus on "types are great, every language must have them". They, in general, do not acknowledge trade-offs when it comes to type systems…

> > 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 be done at runtime, by the programmer.

Re: A perfectable programming language

#93

Post by ModernMech »

nobleach wrote: post #86
ModernMech wrote: post #72

Earlier quoted context omitted.

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

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".

Re: A perfectable programming language

#94

Post by jerf »

tizzy wrote: post #64
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,…

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?

"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.

Re: A perfectable programming language

#95

Post by jerf »

lelanthran wrote: post #49
shevy-java wrote: post #32

> languages without types tend to grow them, like PHP in 7.4 and Python type annotations Well ... that is a trend that is driven largely by people who love types. Not everyone shares that opinion. See ruby. It is very hard to try to argue with people who love types. They will always focus on "types are great, every language must have them". They, in general, do not acknowledge trade-offs when it comes to type systems…

> > 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 eventually overwhelm the benefits by almost any standard, but the trend is universal and fairly clear.

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.

Re: A perfectable programming language

#96

Post by matt_kantor »

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 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).

Re: A perfectable programming language

#97

Post by matt_kantor »

tizzy wrote: post #64
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,…

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.

Re: A perfectable programming language

#98

Post by utopiah »

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 reach of JavaScript

Re: A perfectable programming language

#99

Post by jolt42 »

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

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

Re: A perfectable programming language

#100

Post by pydry »

iLemming wrote: post #87
harperlee wrote: post #66

Earlier quoted context omitted.

The question then is how they plan to avoid The Lisp Curse (in my words, language giving you too much power makes you do weird things, and you attract people to like to use things a tad too powerful / generic, and you end up with an unproductive culture).

> 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...

Post reply on HN