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

61–70 of 108 posts

Re: The perfect programming language

#61

Post by atilaneves »

lllr_finger wrote: post #53
atilaneves wrote: post #50

> but as soon as you enter a physics-institution anywhere in the world, FORTRAN likely reigns supreme Not at CERN, but it used to be the case. It's C++ now. > It turns out that FORTRAN is a very good match for the way physicists think about their work I don't even know what this means and I have a PhD in Physics. > You simply specify what fields you have and what pattern they are written in and the computer takes car…

> 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 the lack of generics.

Switching to Python, I'd much rather read:

    [x for x in xs if x % 2 == 0]
Than:

    res = []
    for x in xs:
        if x %2 == 0:
            res.append(x)
3 lines of boilerplate to do 1 line of work. Pass.

Then there's the fact that everything is mutable in Go, so I have to track every and all variables in case they change.

All in all, for me, reviewing code written in it is harder, not easier.

Re: The perfect programming language

#62

Post by fnordsensei »

dustingetz wrote: post #20

clojure is very close - declarative data programming - embraces immutability - hosted (jvm, js) - host ecosystem compatibility - principled culture

Possibly with regards to simplicity as well, depending if the author means "not (objectively) complex" or "not (subjectively) hard."

The "ability to know everything about the language" seems to (possibly) point to simplicity as "not complex", but the discussion around "what you already know" seems to point to the interpretation of "not hard."

I'm not sure I understood the paragraph as it was intended.

Re: The perfect programming language

#63

Post by jstimpfle »

pjmlp wrote: post #60
G4BB3R wrote: post #10

Earlier quoted context omitted.

There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…

While C++ does indeed take lots of time to compile, it is possible to reduce the compilation time quite drastically. - Write modular applications and make use of binary libraries instead of compiling the world from scratch - Enable incremental compilation, incremental linking and pre-compiled headers - Don't go crazy with compile time algorithms / meta-programming

Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers...

But still, moving code from headers to implementation files helps reduce build times. (Very innovative!)

Where I work, the stuff I do in C compiles in less than a tenth of the time. And that's compared to MFC-era C++ (C with classes, not C++11).

Re: The perfect programming language

#64

Post by pjmlp »

jstimpfle wrote: post #63
pjmlp wrote: post #60

Earlier quoted context omitted.

While C++ does indeed take lots of time to compile, it is possible to reduce the compilation time quite drastically. - Write modular applications and make use of binary libraries instead of compiling the world from scratch - Enable incremental compilation, incremental linking and pre-compiled headers - Don't go crazy with compile time algorithms / meta-programming

Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers... But still, moving code from headers to implementation files helps…

I don't touch C unless obliged to do so.

Re: The perfect programming language

#65

Post by ebruchez »

hyperpallium wrote: post #37
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.

XSLT syntax (x < 10) would be its worst problem, except for its other problems. But seriously, XSLT's recursive templates are a nice idea for transformation, and the homoiconicism enables transformation of XSLT stylesheets theselves.

You can write `x lt 10` since XSLT 2.0 in 2007.

Re: The perfect programming language

#66

Post by jstimpfle »

pjmlp wrote: post #64
jstimpfle wrote: post #63

Earlier quoted context omitted.

Congratulations, I believe you've just described C. Unless you use heap allocated objects with virtual destructors and packed in smart references everywhere. If you don't, headers will just include other headers will include other headers... And you end up waiting for minutes for the rebuild whenever you make one tiny change in one of these headers... But still, moving code from headers to implementation files helps…

I don't touch C unless obliged to do so.

So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.

Re: The perfect programming language

#67

Post by pjmlp »

jstimpfle wrote: post #66
pjmlp wrote: post #64

Earlier quoted context omitted.

I don't touch C unless obliged to do so.

So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.

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

Re: The perfect programming language

#68

Post by bwanab »

I worked at one of those other company's that designed Ada specs that didn't get selected, but we did do the first official ALS (Ada Language System).

"first Ada was so complex that even the compilers had performance problems, so there was a bit of a delay getting it out"

This was largely true. The complexity of compilation really bit. But,

", and then, second, C and Unix happened"

This is silly. Unix and C had been around for years before Ada's design was accepted. I'd been working on C in a Unix environment for five years when I started working on Ada. In fact that's why I was hired since one of our first target ALS implementations was for Unix which included several C system level drivers.

Re: The perfect programming language

#70

Post by jstimpfle »

pjmlp wrote: post #67
jstimpfle wrote: post #66

Earlier quoted context omitted.

So, unique_ptrs and virtual destructors everywhere? Or value-type structure embeddings where everything depends on everything else in the public interface? I don't think there's a lot of middle ground.

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 assert you, these things exist, and they are very common.

How do you deal with the situations where only a subset of the enum values is applicable anyway? Because these situations are extremely common as well, and once again, types can't help here without A LOT of additional boilerplate.

> lack of namespacing

It's a feature, not a bug, to know that every thing is referenced by exactly one name. Makes reading code so much easier.

Post reply on HN