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

151–160 of 169 posts

Re: Programming Language Checklist

#151

Post by afiori »

NOGDP wrote: post #104
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…

The amount of compiler and language theory needed to design a language that is also practical to use and implement is far greater than what a UI designer needs to know about web technology. If there was a language designer that wasn't also very knowledgeable about the implementation and use side of things, they would probably be pretty useless outside of syntactic sugar type stuff.

On the other hand experts in their own field have a better chance at having a complete idea if what is needed.

For example, from a theoretical computer science perspective of programming languages handling backwards incompatible change is not a hot topic. Or also compiling ergonomics (as a slight counterexample to my own point, stack, the build system for Haskell has a shebang mode where you can take a Haskell source file and transform it into an executable by prefixing some magic comments)

Re: Programming Language Checklist

#152

Post by lispm »

iLemming wrote: post #142
shadowgovt wrote: post #77

When I was younger, I imagined there would come along a true language that would solve my problems. It took me a long time (and a lot of banging my head into bad environments) to realize that language matters a lot less when the IDE is well-configured and fluent with what I want to do, the toolchain allows for experimentation without ruining the ability to do large, collaborative work, and both debugging and profilin…

> when the language itself (spec and implementation) is constantly in flux. Common Lisp and Clojure are legendary for their stability. So many times I have experienced it myself - I would pick up a 5-6 year old Clojure project, update a bunch of dependencies, and somehow most things work right off the bat. That trick never worked for me with pretty much any other language - C#, Java, Python, Ruby, Go, Lua, Javascript…

I thought Common Lisp is stable because the standard is unchanged since its publication in 1994.

Lisp dialects have a lot of syntax. Every macro implements syntax.

Re: Programming Language Checklist

#153

Post by slifin »

leshow wrote: post #112
shadowgovt wrote: post #77

When I was younger, I imagined there would come along a true language that would solve my problems. It took me a long time (and a lot of banging my head into bad environments) to realize that language matters a lot less when the IDE is well-configured and fluent with what I want to do, the toolchain allows for experimentation without ruining the ability to do large, collaborative work, and both debugging and profilin…

A language is a tool that was built to solve some kind of problem, but no language is built to be the best at all problems. There are pros and cons to using it depending on the task just like anything else. You have to consider what you want to do and pick and language that aligns with your goals.

Clojure is good for this because it's a parasitic language it sits on top of and interops with JavaScript, Java, .NET, Erlang and their ecosystems, npm, maven etc

Learn the main language once and you get incredible reach, for every new runtime the core language is practically the same

Re: Programming Language Checklist

#154

Post by fctorial »

tsimionescu wrote: post #131
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 tha…

Loops are not expressions in python.

Re: Programming Language Checklist

#155

Post by zmmmmm »

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…

What you ask for is what has been going on in the JVM space for 20 years or more. At a lower level, LLVM is similar too.

Re: Programming Language Checklist

#156

Post by tsimionescu »

fctorial wrote: post #154
tsimionescu wrote: post #131

Earlier quoted context omitted.

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

Loops are not expressions in python.

Many things are not expressions in Python. My point was that the community is hostile to making (some of) them expressions, as was seen with the controversy over adding := as an assignment expression (so you can do `if x:=y`, for example).

Re: Programming Language Checklist

#157

Post by ncmncm »

iLemming wrote: post #145
ken wrote: post #4

Of course, every successful language could be roasted with this, too. It's a cute post but if there were a simple checklist for creating a successful language, every language designer would just do that.

Define "successful language". Popularity of a programming language doesn't mean success. COBOL, Fortran and Pascal used to be hugely popular, now with every passing year, it is costing more and more money to support systems that once considered as "successfully built". Sadly, it seems in a few decades, pretty much that would be the fate of every single PL in TIOBE's Top. All popular PLs of today are morally outdated.…

Pascal has never been popular. Certain offshoots of Pascal got popular, none so much as Delphi. Which some people still use.

Re: Programming Language Checklist

#158

Post by ncmncm »

F-0X wrote: post #25
qaq wrote: post #21

Earlier quoted context omitted.

"but it has basically no effect on quality of the code" well if you include number of bugs of certain class as a criteria of quality it would be pretty hard to argue that there is no difference between say Rust and C.

I think C has better syntax than Rust, by miles. Rust's syntax is the bastard child of C++ and OCaml and is more than the sum of its parts. Rust code having fewer bugs has absolutely nothing to do with its syntax.

I have coded C since 1984, and C++ since 1988. I found Rust syntax extremely easy to switch to, but I found switching back to C++ syntax extremely difficult.

Do not learn Rust if you think you might need to code C++ or C ever again.

Rust probably should have used "." in place of ";". Or anything, really.

Re: Programming Language Checklist

#159

Post by ncmncm »

iLemming wrote: post #140
shadowgovt wrote: post #88

Earlier quoted context omitted.

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.

Indeed, no actual compiler or interpreter is needed. Or computer, really. Like the Lambda Calculus, it's a notation for expressing algorithmic ideas. The only right thing to do with an algorithmic idea is to analyze it. Executing just gets your hands dirty, and makes you smell bad.

Re: Programming Language Checklist

#160

Post by iLemming »

ncmncm wrote: post #157
iLemming wrote: post #145

Earlier quoted context omitted.

Define "successful language". Popularity of a programming language doesn't mean success. COBOL, Fortran and Pascal used to be hugely popular, now with every passing year, it is costing more and more money to support systems that once considered as "successfully built". Sadly, it seems in a few decades, pretty much that would be the fate of every single PL in TIOBE's Top. All popular PLs of today are morally outdated.…

Pascal has never been popular. Certain offshoots of Pascal got popular, none so much as Delphi. Which some people still use.

Maybe not in the US. It was pretty popular for example in the USSR back in 1980-90ies.
Post reply on HN