Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Because I believe safety critical places like aviation are the ones that actually get things right. You can't pile on every demand on the human in charge and expect improvement. We're just not great at taking every possible detail into account. Doing lots of grunt work all the time reliably is what we have computers for.

In my old age, I find the more permissive a language is, the more painful it is to code in long term. Perl is great for simple things, but C++ was a vast improvement because it catches a lot of nonsense that Perl will compile just fine.

And debugging is so expensive that eventually writing code fast is near worthless. Whatever you gain you more than pay for in debugging afterwards.

C++ unfortunately doesn't go far enough.



One could actually have both. Spiral provides a lot of its performance by correctly specifying error constraints, which is a form of safety. You could specify architectural constraints by hand too, for performance and portability. (With some good defaults.)

One could technically also get memory and reference safety this way. Which is the opposite of what Rust does for example, where it defaults to do a particular model of referencing memory and makes using any other painful.

It also does not have any constraints on timing or redundancy if necessary.

Automate some of this handling but still keep it explicit and you have a potential winner.


yes - i switched from C to C++ a long, long time ago (late 1980s) because C++ was so much more strongly typed (i still don't understand why other C programmers have stuck with C). i'm less than convinced with the promises of rust (for e.g.), but have only written trivial programs in it.


Because simpler languages are inherently better than more complicated ones.


Simpler languages often put more burden on the programmer.

There's a balance.


Well no, what do you think the word simpler means?


C is a simple language.

Rust is not a simple language.

Lisp is also a simple language.

Lua is simple as well (well… maybe not…)

JavaScript is not.

C++ is not.


C isn't a simple language, really, because it has a ton of implicit assumptions and inconsistencies, undefined behavior and all the failure modes you have to keep in your head at all times.

It's not that C is simpler, it's less expressive.

I don't think this answers parents question though, which is what does it mean for a language to be simpler? I think that's a good question. This is just a list of examples.

It almost seems like simple is a bad concept applied to languages because what's simple and complex is the idea you're trying to express, accurately, in its totality - not necessarily the language.


I think expressiveness is complexity.

The fewer ways there are to express an idea, the simpler the language is.

Simple languages do not imply simple software (look at lisp)


why? says who? assembler (about as simple as you can get) better than (for e.g.) C?


And even simpler is the iota combinator which is by itself turing complete. So a single letter plus matching parens is about the simplest language as you can get. But I can't imagine anyone wanting or even being able to program in it.


Assembler is a bad example for simplicity. Perhaps brainfuck fits better in this case.


Simpler aka Python, Ruby, Basic, Pascal, not "lower level".


"Simpler" isn't really a good adjective to classify languages. You have to be way more specific on what "simple" means. Are we talking characters needed to implement 'hello world?' Time to first memory access segfault? Number of pages in the specification (which, at this point, I'm not sure whether Python or C++ wins out...)? Lines of code in the compiler / interpreter?


i don't see those languages as being "simple". quick to program in, yes. but assembler is really pretty transparent, once you get into it. heck, i used to program in machine code (i don't recommend it) without too many problems.


Good luck programming your next application using the lamda calculus or a Turing machine.




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

Search: