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

The perfect programming language

cygni.se

Post reply on HN
Print view View original

71–80 of 108 posts

Re: The perfect programming language

#71

Post by tome »

mbrock wrote: post #11
nickserv wrote: post #7

Interesting perspectives on a variety of languages, at first. Then when he says that XSLT is the best language I was thinking that we are very differently minded. So I suppose it makes sense that the Tailspin language is completely incomprehensible to me.

The built-in ability to pattern match on data nested deeply within the application state (or the XML document) is radically powerful. Haskell, for example, has nothing like this. Eve is a really interesting language where you define global pattern matches, using datalog-style unification rather than XPath, and these "templates" can result in state changes. So for example you can trivially define global invariants ove…

> The built-in ability to pattern match on data nested > deeply within the application state (or the XML document) > is radically powerful. Haskell, for example, has nothing > like this.

Now I'm puzzled because I know that you know about lenses, so you must mean something different by "pattern match on data nested deeply" and I'm wondering what. Could you expand?

Re: The perfect programming language

#72

Post by tome »

abathologist wrote: post #48
hhas01 wrote: post #6

Earlier quoted context omitted.

The article’s title says “ perfect programming language”. “Impure” means the language design is by definition compromised. The moment you allow imperative behaviors to leak into a declarative system it loses its ability to reason reliably about operations over time; and you’re back to flying seat-of-your-pants a-la C &co. Haskell at least has the good grace to firewall any imperative crap so that the remainder of the…

> The moment you allow imperative behaviors to leak into a declarative system it loses its ability to reason reliably about operations over time; and you’re back to flying seat-of-your-pants a-la C &co By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? I think a more reasonable position allows…

> By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"?

Well no, because for some reason, be it social or technical, people simply don't use unsafePerformIO in way that is actually unsafe.

Re: The perfect programming language

#73

Post by pjmlp »

jstimpfle wrote: post #70
pjmlp wrote: post #67

Earlier quoted context omitted.

Sensible use of language features, and definitely no use of inherited C unsafety features like manual resource management, unchecked arrays accesses, implicit enum conversations, lack of namespacing, nullable pointers instead of references,...

> [no use of] unchecked arrays accesses that requires to include i.e. vector everywhere, which drives up compile times and adds dependencies. Maybe slightly better: some slice type. But it's still a lot of boilerplate, and doesn't play nice with parallel arrays. > [no use of] implicit enum conversations > [no use of] nullable pointers How do you deal with "missing or N/A values"? Because, as every database guy will a…

Binary dependencies that are already compiled, external template instantiation exists since C++11.

I deal with nullable types when needed, not for 100% of pointers, like C requires to.

A feature that requires linker support to work around third party libraries clashes, C engineering at its best.

Re: The perfect programming language

#74

Post by majewsky »

atilaneves wrote: post #58
majewsky wrote: post #51

Earlier quoted context omitted.

> I'm not aware of Go programs that are particularly efficient. Go occupies the same niche as Python, Ruby and JavaScript (server-side business logic). Compared to programs in those languages, Go programs are insanely efficient.

> Go occupies the same niche as Python, Ruby and JavaScript (server-side business logic) Is this in a world in which Java and C# never happened?? > Compared to programs in those languages, Go programs are insanely efficient. In other news, compared to walking, bicycles are insanely fast. Also, let's pretend cars don't exist.

C# only happened in the Microsoft part of the universe for most of its life.

Java has a bad reputation because its community appears to favor over-engineered opaque solutions (that whole ProxyAdapterFactorySingletons business).

Go pushes a quite different style, favoring explicit bindings over dependency injection.

Disclaimer: I write a lot of Go, but I don't have productive experience with C# or Java, except for a semester-long project at university where Spring Boot was mandated. I recall most students having trouble with its implicitness, i.e. they could not build a mental model for why certain changes had certain effects.

Re: The perfect programming language

#75

Post by RodgerTheGreat »

atilaneves wrote: post #61
lllr_finger wrote: post #53

Earlier quoted context omitted.

> efficient development I think the rationale for that is twofold: that as a static typed language that prefers stack allocation, you can get some very good performance without putting much effort into it, and that it's usually clear what the idiomatic way to accomplish something is. On the latter point, I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries. For…

> you can get some very good performance Compared to... ? > I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries. See, I don't. Every for loop has to be inspected to see if it's one of the 99.9% cases where it's a map, reduce, or filter. For loops can't be chained. Error handling takes up over half of a function. An algorithm library can't be written because of…

In K, I'd much rather read

    (~2!)#x
(Not (~) modulo 2 (2!) filter (#) of x.)

Or perhaps more idiomatically,

    x@&~2!x
(x indexed (@) where (&) not (~) modulo 2 (2!) of x.)

Reading a python comprehension requires awkward skipping around, and composing them together is a mess. APL-style uniform precedence is something I wish more languages imitated.

Still, anything's better than an endless sea of for loops.

Re: The perfect programming language

#76

Post by majewsky »

pjmlp wrote: post #57
zozbot234 wrote: post #39

Earlier quoted context omitted.

Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust

Try to write a GUI application, or game, in both C++ and Rust and see which one ends up being more newcomer friendly.

Is it fair to compare GUI frameworks with over 20 years of maturity (Qt, GTK+) with others that are less than a few years old and still mostly in their exploratory stages?

Re: The perfect programming language

#77

Post by protomyth »

RodgerTheGreat wrote: post #45
protomyth wrote: post #24

Earlier quoted context omitted.

I have often wanted a Postscript without the drawing functions to be my quick and dirty language. It really is the nicest stack language I have ever programmed in.

You can use GhostScript as a repl: $ gs GPL Ghostscript 9.19 (2016-03-23) Copyright (C) 2016 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details. GS>2 3 add stack pop 5 GS> Many of you probably already have it installed on your machines!

GhostScript is a little too heavy weight for what I want and I would need stdio access. Good tip though, thanks.

Re: The perfect programming language

#78

Post by pjmlp »

majewsky wrote: post #76
pjmlp wrote: post #57

Earlier quoted context omitted.

Try to write a GUI application, or game, in both C++ and Rust and see which one ends up being more newcomer friendly.

Is it fair to compare GUI frameworks with over 20 years of maturity (Qt, GTK+) with others that are less than a few years old and still mostly in their exploratory stages?

It is, because the issue is the language semantics to deal with typical UI workflows.

You are forced to use Rc> and clone everywhere, or copy objects around, reactive style, to kind of work around borrow checker ergonomics.

Re: The perfect programming language

#79

Post by yellowapple »

RodgerTheGreat wrote: post #75
atilaneves wrote: post #61

Earlier quoted context omitted.

> you can get some very good performance Compared to... ? > I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries. See, I don't. Every for loop has to be inspected to see if it's one of the 99.9% cases where it's a map, reduce, or filter. For loops can't be chained. Error handling takes up over half of a function. An algorithm library can't be written because of…

In K, I'd much rather read (~2!)#x (Not (~) modulo 2 (2!) filter (#) of x.) Or perhaps more idiomatically, x@&~2!x (x indexed (@) where (&) not (~) modulo 2 (2!) of x.) Reading a python comprehension requires awkward skipping around, and composing them together is a mess. APL-style uniform precedence is something I wish more languages imitated. Still, anything's better than an endless sea of for loops.

I'm disappointed that these are not valid Perl programs (the first is a syntax error, and the second complains about an array where an operator is expected).

Re: The perfect programming language

#80

Post by teyc »

RodgerTheGreat wrote: post #75
atilaneves wrote: post #61

Earlier quoted context omitted.

> you can get some very good performance Compared to... ? > I appreciate golang's simplicity when I need to review other people's code or dig into third party libraries. See, I don't. Every for loop has to be inspected to see if it's one of the 99.9% cases where it's a map, reduce, or filter. For loops can't be chained. Error handling takes up over half of a function. An algorithm library can't be written because of…

In K, I'd much rather read (~2!)#x (Not (~) modulo 2 (2!) filter (#) of x.) Or perhaps more idiomatically, x@&~2!x (x indexed (@) where (&) not (~) modulo 2 (2!) of x.) Reading a python comprehension requires awkward skipping around, and composing them together is a mess. APL-style uniform precedence is something I wish more languages imitated. Still, anything's better than an endless sea of for loops.

The Python expression closely represents how it is done in maths.

    {x∣x∈N,x
Post reply on HN