I think Go could be fundamentally improved if it somehow offered a REPL.
The perfect language and why Go still isn't it
11–20 of 139 posts
Re: The perfect language and why Go still isn't it
#12It's a futile quest to find the perfect programming language. Any language that gains popularity will face a vocal demand for new features at some point. But it's not just about adding new concepts. Programmers also want new shortcuts for existing features to save them a few keystrokes. That then entails issuing recommendations on when to use such shortcuts to keep code consistent.
There are plenty of small languages, but they lack popularity or rich libraries. The only language I can think of that remains in widespread use and is fairly small in language size is C.
I'm strongly in the camp that small languages are preferable to large ones and wish language designers would follow this principle more closely. But small does not necessarily mean more readable. And language syntax design remains a neglected aspect of programming language design.
Re: The perfect language and why Go still isn't it
#13It's a futile quest to find the perfect programming language. Any language that gains popularity will face a vocal demand for new features at some point. But it's not just about adding new concepts. Programmers also want new shortcuts for existing features to save them a few keystrokes. That then entails issuing recommendations on when to use such shortcuts to keep code consistent. There are plenty of small languages…
Even C is full of features if you compare C11 with K&R C, and C20 is already ongoing.
And if we consider the amount of compiler specific C extensions, across all C implementations, it gets even bigger.
Re: The perfect language and why Go still isn't it
#14I think Go could be fundamentally improved if it somehow offered a REPL.
Checkout https://github.com/containous/yaegi . Don't think its very mature though.
Re: The perfect language and why Go still isn't it
#15F# hits all his 'perfect language' points for me. It feels like a more concise, opinionated and beautiful refinement of C#.
Re: The perfect language and why Go still isn't it
#16This already exists, but it isn't trendy. It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust. It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap. Try all…
As much as I like Pascal, and I am a big fan since Turbo Pascal since version 4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of automatic memory management is a killer for anyone that cares about code security. Delphi only supports it for COM and Objective-c/Swift interoperability, everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in that regard.
RemObjects Oxygene does. All targets have a GC (boehm on win32,64, Linux and Darwin, .net and java have their own of course) or arc (cocoa).
Re: The perfect language and why Go still isn't it
#17Earlier quoted context omitted.
As much as I like Pascal, and I am a big fan since Turbo Pascal since version 4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of automatic memory management is a killer for anyone that cares about code security. Delphi only supports it for COM and Objective-c/Swift interoperability, everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in that regard.
RemObjects Oxygene does. All targets have a GC (boehm on win32,64, Linux and Darwin, .net and java have their own of course) or arc (cocoa).
Thanks for the heads up.
However that isn't Free Pascal, which was the OP's point.
Having said that, RemObjects Oxygene is probably an alternative then. :)
Re: The perfect language and why Go still isn't it
#18This already exists, but it isn't trendy. It's FreePascal. Nobody believes me, but we have perfection already. No crap you don't need. No crazy corner cases. No C++ templated metaprogramming lambda auto pointer garbage. No "I can't write a linked list without a Grimoire" Rust. It's great. You get a ton done, and simply ignore the language wars. No VM trash (Java). No web trash (JavaScript/"Webasm"). No crap. Try all…
As much as I like Pascal, and I am a big fan since Turbo Pascal since version 4 for MS-DOS, using all of them until about Delphi 3, lack of some kind of automatic memory management is a killer for anyone that cares about code security. Delphi only supports it for COM and Objective-c/Swift interoperability, everything else is as manual as TP for MS-DOS, and I bet FP hasn't improved in that regard.
Ah, a young lad :) I started tinkering with Turbo Pascal 3 and even have some experience with Pascal on the Apple II. (Not because I am THAT old, but that were the only computers my school had at the end of the 80ies)
The successors of Pascal are also highly interesting. I used Modula-2 quite a lot, but never got deep into Oberon. I do think one big advantage of Go is, that it so strongly draws on the Wirth languages that it almost can be considered a modern successor.
And I fully agree, one shouldn't use a language these days for general programming without some kind of automatic memory management. Which is the other aspect which drew me towards Go, a nice nativley compiled language with a GC.
Re: The perfect language and why Go still isn't it
#19Let me break it to you, there is no perfect language, just the ones most general purpose enough to cover most common problems and most suited for your applications. Each language has it own use and one doesn't trump another in terms of functionality or usage, they only compete when they lie in the same paradigm and this is where most language oriented comparisons are drawn whether be it time of execution or performance. This is also why there are more than one language within the same paradigm, as each one tends to have it's own intricacies and features that was solely developed for the purpose of improving upon it's predecessor. So there you are, stuck with more than one language to suit your needs and hence the untenable need for a perfect language.
Also, trying to bend a certain language to adopt features and functionality that are unwarranted for it's use cases is another reason for the criticism some languages draw upon from the community, therefore it's best for the language to stick to what it does best and stop it at that instead of trying to fit in to uses which it was never intended for when it was first developed. But the language itself is agreeable to evolve through time, but to constrain itself to it's actual purpose would be better for both the language and it's users.
Re: The perfect language and why Go still isn't it
#20F# hits all his 'perfect language' points for me. It feels like a more concise, opinionated and beautiful refinement of C#.
I really like F#, but it has a few major pain points that hinder adoption:
The first is that once a user reads over the various functional things like let statements, record types, union types...etc, you still don't really know how to code in F# unless you already have a .NET and in particular C# background. Nearly all the documentation and books (I have 3 of them) assume you're a C# dev making the switch. This is similar to learning Clojure/Kotlin/Scala on the JVM without knowing any Java. Everytime I post this someone tells me that is untrue, so I give it another shot and an dissapointed. With Python, there are dozens of books written for beginners that show you the building blocks (lists, control flow, dictionaries, tuples, functions, classes, file IO...etc) and how to use the blocks to build useful programs. With F# you get three sentences in and then hear how this is just like this thing in C# that I also know nothing about.
Microsoft also seems to not be very dedicated to providing F# tooling support.
On the plus side, I've found the community to be super smart and helpful and the language itself is very beautiful from an aesthetics point of view to me somehow (just looking at a bunch of code ). In comparison to C#, there is sooo much less noise (); everywhere.
Go is a pretty simple language that compiles to static binaries. F# ain't that as there is all the bloat and baggage of .NET. Even with .NET core, that is more confusion for me.