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

Programming Language Checklist

famicol.in

Post reply on HN
Print view View original

131–140 of 169 posts

Re: Programming Language Checklist

#131

Post by tsimionescu »

jupp0r wrote: post #128

Is there anybody who would argue against: - everything is an expression - destructuring - support for higher order functions Those seem to be universally loved features that new programming languages are required to have in order to still be appealing.

While I personally agree with you, I know that some people really hate 'everything is an expression', especially when assignment is treated as an expression. This has been a very controversial addition to Python 3 for example.

I would also mention that support for higher order functions, in the sense of functions which take other functions as arguments, is eevn possible in C. I think a much more important feature that is only recently becoming mainstream is support for lambdas. Support for HoF without lambdas is relatively worthless in my opinion.

Re: Programming Language Checklist

#132

Post by exdsq »

zem wrote: post #24
hardwaresofton wrote: post #12

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.

there are tons of multiparadigm languages, but oz/mozart in particular is worth a glance: https://mozart.github.io/mozart-v1/doc-1.4.0/tutorial/index....

It’s also notable in that Mozart is based on Pi Calculus. Except for Pict, I’m not aware of any others.

Re: Programming Language Checklist

#133

Post by AzzieElbab »

zem wrote: post #24
hardwaresofton wrote: post #12

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.

there are tons of multiparadigm languages, but oz/mozart in particular is worth a glance: https://mozart.github.io/mozart-v1/doc-1.4.0/tutorial/index....

but those are teaching languages, specifically designed to teach multiple pl paradigms

Re: Programming Language Checklist

#134

Post by darkkindness »

everdev wrote: post #91

> [ ] Syntax is what makes programming difficult I'd love to see language design and language development treated as different disciplines. Just like developers were the first web designers, developers have been the first language designers. Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax. Language developers would be tasked with everything else: basic…

This might interest you (and anyone reading this thread): AnyDSL is a language framework that separates the concerns for both viewpoints (designing for expressivity, designing for abstracting 'complex ideas') but also that of the machine expert (designing for efficiency). I'm not affiliated with AnyDSL, I'm just parroting the blurb on its main site[0]:

> When developing a DSL, people from different areas come together:

> - the application developer who just wants to use the DSL,

> - the DSL designer who develops domain-specific abstractions, and

> - the machine expert who knows the target machine very well and how to massage the code in order to achieve good performance.

> AnyDSL allows a separation of these concerns using

> - higher-order functions,

> - partial evaluation and,

> - triggered code generation.

[0] https://anydsl.github.io/

Re: Programming Language Checklist

#135

Post by rbonvall »

nudq wrote: post #108
everdev wrote: post #91

> [ ] Syntax is what makes programming difficult I'd love to see language design and language development treated as different disciplines. Just like developers were the first web designers, developers have been the first language designers. Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax. Language developers would be tasked with everything else: basic…

> a linguist (with some understanding of development) Your wish has been granted: Larry Wall, Perl 6.

And, for that matter, Perls 0, 1, 2, 3, 4, and 5.

https://perldoc.perl.org/perlhist.html#INTRODUCTION

Re: Programming Language Checklist

#137

Post by musicale »

dear C, unfortunately you lack: a memory safe compilation mode for gcc and clang, non-clunky syntax for iterators and abstractions

dear python3, unfortunately you lack: print statement, fast/any type checking, concurrency, speed

dear java/golang/javascript et al., unfortunately you lack: named parameters, default parameters, predictable performance

dear nearly everyone except ada/oberon/et al., unfortunately you lack: sensible numeric types/subtypes and ranges

Re: Programming Language Checklist

#138

Post by AnimalMuppet »

tluyben2 wrote: post #18
cryptica wrote: post #11

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

> the syntax doesn't really matter at all. Somehow it does though: I find even j/k/apl easier to parse in my head than Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far nicer to read and write. And, even though I understand the semantics and can write code in Ruby, if I have a choice, I would never touch it again.…

Syntax matters. But...

1. Other things matter more. How a language scales to 100 programmers working on 10 million lines over 20 years, say, matters more (in some environments) than the syntax does. Syntax contributes to that. But syntax contributes to that precisely by being pretty vanilla, uninteresting syntax. More, sexier syntax makes a language worse for that environment. (I'm talking about go here. But I could make a similar argument for other languages in other environments.) Syntax matters as a means to an end; the end matters. Syntax where the end is syntax doesn't matter so much.

2. I suspect (and assert without proof) that peoples' brains work in different ways, and that a person finds languages easier or harder as those languages conform or conflict with the way the person thinks. Ruby syntax gives you a headache? And the problem isn't that you just need to learn Ruby better. But for every you, there's (at least one) someone who has the same issue with J/K/APL. And that's fine. People whose way of thinking matches APL should program in APL, and those whose way of thinking matches Ruby should program in Ruby. We don't need one language to rule them all. They each have their target niche and their target audience.

Re: Programming Language Checklist

#139

Post by iLemming »

tluyben2 wrote: post #18
cryptica wrote: post #11

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

> the syntax doesn't really matter at all. Somehow it does though: I find even j/k/apl easier to parse in my head than Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far nicer to read and write. And, even though I understand the semantics and can write code in Ruby, if I have a choice, I would never touch it again.…

> I know quite a lot of Lisp-y coders (most of them do Clojure these days) and they don't understand how/why you would ever use anything else

Because Lisps emphasize data more than the syntax. The following quote is from Rich Hickey's famous: "Simple Made easy" talk:

Syntax, interestingly, complects meaning and order often in a very unidirectional way. Professor Sussman made the great point about data versus syntax, and it's super true. I don't care how many you really love the syntax of your favorite language. It's inferior to data in every way.

Re: Programming Language Checklist

#140

Post by iLemming »

shadowgovt wrote: post #88
mapcars wrote: post #8

[ ] You require the compiler to be present at runtime [ ] You require the language runtime to be present at compile-time The guy never heard of Lisp so I wouldn't pay much attention to this anyway.

I'm sure the authors have heard of Lisp. And I suspect the authors are making a dig at the fact that Lisp is now over 60 years old and its popularity has been dwarfed by many, many "worse" languages (partially because Lisp has several properties that are checkboxes in this list ;) ).

You're making a classic mistake - Lisp is not a language. It's a set of ideas. Some brilliant ideas. Pretty much every single PL that in use today was influenced by those ideas. There's plenty of Lisp in Python and Javascript. And pretty much there's a Lisp dialect and compiler/transpiler/interpreter for every platform today. Lisp (despite being over 60 years old) never went out of fashion and I doubt it ever will.
Post reply on HN