Live data from Hacker News

Programming Language Checklist

famicol.in

61–70 of 169 posts

Re: Programming Language Checklist

#61
post #49
post #14

I got an idea for a language where the code in the file format is some intermediary language, which you write with an editor plugin that makes it more human-readable. The editor plugin (in contrast to existing language plugins) also translates the error msgs back to the human-readable code. Just an idea, but I could not get it to fit in the questionaire :)

Congratulations, you just invented AppleScript!

i feel it's more like LISP (the AST is the language) or like Haskell's or Rust's intermediary languages.

Re: Programming Language Checklist

#62
post #14

I got an idea for a language where the code in the file format is some intermediary language, which you write with an editor plugin that makes it more human-readable. The editor plugin (in contrast to existing language plugins) also translates the error msgs back to the human-readable code. Just an idea, but I could not get it to fit in the questionaire :)

This sounds like assembler.

That's waaaay to low level for what I had in mind.

Re: Programming Language Checklist

#63
post #28

> [ ] You have reinvented Javascript but worse > [ ] You have reinvented PHP but worse I'm trying to think of languages that would fit that bill. That almost sounds like a challenge.

Brainfuck [0], Whitespace [1] and INTERCAL [2] come to mind :)

Of course, one could argue none of these are 'serious' programming languages.

---

[0]: https://en.wikipedia.org/wiki/Whitespace_(programming_langua...

[1]: https://en.wikipedia.org/wiki/Brainfuck

[2]: https://en.wikipedia.org/wiki/INTERCAL

Re: Programming Language Checklist

#64

>> You appear to believe that: Syntax is what makes programming difficult This is exactly the problem. People spend so much effort looking for better syntax that they miss the most important part of programming. It's about design and structure, the syntax doesn't really matter at all. I don't even care if it's dynamically typed or statically typed or functional or not. A bad developer will produce bad code no matter…

,,I've written code in many languages and I can produce good software with any of them. '' If you write code yourself and view that as the main advantage, type systems matter less. But when working in a team having statical typing as a written contract between people can help development substantially.

Public interfaces should ideally be formally typed, both to provide a behavioral contract between parties and to serve as user documentation. Whether the contract is enforced at compile- or run-time is secondary to having a formal mechanism for expressing it in the first place; ditto whether the code hidden behind those interfaces is explicitly typed, inferred, or untyped.

Two problems that tend to occur in practice:

* Untyped languages (e.g. Python, Ruby, JavaScript) typically lack a formal dialect for expressing parameter and result types, and most don’t even provide formal mechanism for annotating interfaces. Without a common language for expressing interface types, it’s nigh impossible to develop the tooling and education that are the necessary prerequisites to popular adoption.

* Typed languages (e.g. C†, Java, Swift) frequently have poor/limited expressivity, creating friction for users, who end up fighting against the type system instead of working with it to describe their precise needs, while failing to provide the promised safety. e.g. Inability to describe numeric bounds means many functions with integer/double parameters will be partial, and passing inappropriate values will trigger runtime errors/aborts/undefined behaviors (e.g. divide-by-zero, bad array index). And that’s just the easy stuff.

Python3 is one exception to the former, in that function interfaces can be formally annotated, though the language itself doesn’t provide the mechanism to enforce those annotations. And Eiffel is something of an exception to the latter in that interfaces are annotated with a mix of compile- and run-time checks. And then, of course, there’s ongoing work on dependent type systems and no doubt other CS research that may someday filter down into the production languages in mainstream use. But it’s tough and slow, and a giant wildly-inconsistent ballache in the meantime, with more really badly reinvented wheels than it’s possible to count.

-- † Inasmuch as C can be said to have a “type system” at all (Really, it’s just got a handful of annotations for allocating memory on stack.)

Re: Programming Language Checklist

#65
post #58

Earlier quoted context omitted.

Almost every language is multi paradigm (it just takes two paradigms after all, so every imperative OOP language is multi paradigm). All the most popular languages today have a mix of imperative, functional and OOP. Few languages (and certainly fewer popular ones) are paradigmically “pure”.

> every imperative OOP language is multi paradigm I am not sure how you can count imperative and OOP as two paradigms. OOP is an extension of imperative paradigm. I would like to see what language you consider to be OOP but not imperative and not functional.

In the spirit of a bit of fun, Erlang can arguably make that claim. The processes are easy to view as objects, in the sense that I've often thought that when I read what Alan Kay said about objects, it often seems to be describing Erlang moreso than Smalltalk. But the language those objects are implemented in is functional.

(That said, if you read real Erlang code, despite being immutable and nominally functional, the code often is in practice simply imperative code where the code author has manually done the SSA rewrite. This is one of my major criticisms with the language. If you really try to program it functionally, it's quite a pain compared to Haskell.)

Re: Programming Language Checklist

#66

Making a language is fun, and builds your skills. I'd rather work with a person who has made a bad language than someone who has never made one. Don't make fun of people for making languages.

This checklist is, to my eyes, making fun of people who make fun of languages.

Well, if that's the case, I can do you one better.

Re: Programming Language Checklist

#67

Making a language is fun, and builds your skills. I'd rather work with a person who has made a bad language than someone who has never made one. Don't make fun of people for making languages.

I make languages and I LOLed. Self-awareness, good knowledge of CS history, and a huge heaping helping of humility are all key prerequisites to inventing a language that is even marginally less appalling than all of its predecessors. “You will FAIL” is about the best advice a nascent language designer can receive, and they should embrace it.

Also Obligatory:

http://james-iry.blogspot.com/2009/05/brief-incomplete-and-m...

Re: Programming Language Checklist

#68
post #14

I got an idea for a language where the code in the file format is some intermediary language, which you write with an editor plugin that makes it more human-readable. The editor plugin (in contrast to existing language plugins) also translates the error msgs back to the human-readable code. Just an idea, but I could not get it to fit in the questionaire :)

This reminds me of "programming ligatures": https://github.com/tonsky/FiraCode

Re: Programming Language Checklist

#69

Earlier quoted context omitted.

I also chuckled at the '[ ] "multi-paradigm"' and immediately thought of lisp since it's one of the only languages that's ever had a reason to lay claim to that. If you think about it, lisp is really just the smallest amount of higher-level PL primordial soup you can give to a programmer.

Almost every language is multi paradigm (it just takes two paradigms after all, so every imperative OOP language is multi paradigm). All the most popular languages today have a mix of imperative, functional and OOP. Few languages (and certainly fewer popular ones) are paradigmically “pure”.

“Almost every language is multi paradigm”

Considering most language paradigms are mutually contradictory, this only serves to increase the LOLs.

Re: Programming Language Checklist

#70
post #63
post #28

> [ ] You have reinvented Javascript but worse > [ ] You have reinvented PHP but worse I'm trying to think of languages that would fit that bill. That almost sounds like a challenge.

Brainfuck [0], Whitespace [1] and INTERCAL [2] come to mind :) Of course, one could argue none of these are 'serious' programming languages. --- [0]: https://en.wikipedia.org/wiki/Whitespace_(programming_langua... [1]: https://en.wikipedia.org/wiki/Brainfuck [2]: https://en.wikipedia.org/wiki/INTERCAL

Are they even similar to JavaScript or PHP?
Post reply on HN