41–50 of 108 posts
When a programming blog has a headline which teases knowledge of the perfect technology, the answer is always “I don’t know”.
Both baits work on me, apparently, but I sure wish they didn’t.
> The foremost is simplicity, that a language should be simple enough that the programmer should be able to know everything about it. Well, no. Translated - "a language should serve the lowest possible denominator". Apart from the obvious fact that it is impossible, it's also definitely not the way to go if you want quality software.
There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…
I would not call Java complicated at all. The way they wrote some over-engineered libs for it however is a different story. FactoryFactoryFactory my a$$. I personally do not like Java for performance related reasons and inability to do some lower level tasks but for generic enterprise development those features are not really needed.
As for C++ - yes it IS SUPER COMPLICATED . I do not know all of it and do not give a flying hoot about this fact. What good about C++ for me personally is that basic stuff is easy enough to comprehend and I have no problem mostly sticking to C with classes approach. However whenever I feel that I need some exotic "feature" usually I can do a bit of reading and find it.
Build time is not great but at least in my cases incremental compile time is fine.
My only real problem with C++ is when I need to use some third party piece of code and it is written by some cool person who has decided to write it using every feature of language available and suddenly I can not comprehend what does every second f..ng line mean.
Sad to see no mention of the impure ML languages (OCaml, F#, PureScript, etc). For me these strike a great balance between powerful abstractions and the ability to throw things together.
and rust wasn’t mentioned!
There seems to be a happy point in languages where it's easy enough to get up and running, but complex enough to come back through and tighten things up. Like how Python allows a secondary file for parameter types in the function signatures. Also how tools like Flow for javascript has the bolt on type checking. To me, the perfect language seems to be one that does the annoying things like that for you and lets the pr…
Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust
Compared to, say Javascript, Ruby, or Go, Rust has a secondary set of rules that programmers have to learn before they can even do the most simple things. As an experienced programmer, I look at most Rust code with bewilderment. This is after a week of studying the language.
I can look at Python and instantly understand what's happening, without any knowledge of the language. I can look at Go's standard library code and instantly know what it's doing, without any previous knowledge of the language. That seems to me to be the goal of a language. I don't know much about those languages and if they scale or whatever, but they look like they'd be productive.
I look at most C++ and it's on the edge of being incomprehensible if anyone does anything remotely abstract. And that's with 10+ years of experience in the language.
Rust, to me seems like it chooses to prioritize memory correctness and speed over everything else, including productivity. Maybe I'll hack away at learning it for another few weeks and something will click, but for now it's an uphill battle. That to me is a barrier to entry that will not help it gain traction.
One language that seldom gets mentioned is Postscript. People tend to think of it as just a page descriptor language, but really that is just the built-in graphic functions. So we have a post fix (RPN, similar to HP calculators) expression style, which is really a mirror image of Lisp. You have genuine first class functions, introspection, and something I don't see that often is first class environments. That is you…
I have often wanted a Postscript without the drawing functions to be my quick and dirty language. It really is the nicest stack language I have ever programmed in.
$ gs
GPL Ghostscript 9.19 (2016-03-23)
Copyright (C) 2016 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
GS>2 3 add stack pop
5
GS>
Earlier quoted context omitted.
Also no mention of anything in the APL family, sadly.
Indeed. The relevant part of k \h can be put on one side of a postcard.
Earlier quoted context omitted.
Here's another list of factorial implementations in Haskell, which I think does say something about the language and its mindset. Be sure to scroll to the end: https://www.willamette.edu/~fruehr/haskell/evolution.html Here's another illustration. Since values in Haskell are immutable, implementing something like foo.bar.baz+=1 becomes a bit clunky, so they wrote a library to make it easier. Check it out, especially t…
I would like to see a concerted effort from the Haskell community to set aside the self-gratifying maps and factorials, and show us real work. The OP article, too, focusing on reducing errors, went into the factorial weeds here. How about presenting the air traffic control example in Haskell to contrast with the Ada? Real concurrency, real I/O, and real error cases.
It's very nice for some algorithms. For example, see Appendix A of this paper: https://pdfs.semanticscholar.org/b47b/41a9b2dcf6b3ffe3ce7a04... An implementation of red-black trees in only 60 lines, including deletion, which alone can take hundreds of lines in a curly brace language.
It's also very nice for some APIs. For example, software transactional memory fits the Haskell type system very well, because it can ensure that data can't be modified outside a transaction and can be rolled back when needed. A team at Microsoft, including some well-known folks, tried to port it from Haskell to C# and failed due to the type system: https://www.infoq.com/news/2010/05/STM-Dropped/
Haskell has a bunch of non-mainstream features that work together unusually well. It enables programmers to think a certain kind of thoughts that wouldn't naturally arise in many other languages. It's like painting with oil when the rest of the world uses watercolor: in theory they can draw the same things, but in practice they'll guide your hand toward different things, so having both makes the world richer.
Sad to see no mention of the impure ML languages (OCaml, F#, PureScript, etc). For me these strike a great balance between powerful abstractions and the ability to throw things together.
The article’s title says “ perfect programming language”. “Impure” means the language design is by definition compromised. The moment you allow imperative behaviors to leak into a declarative system it loses its ability to reason reliably about operations over time; and you’re back to flying seat-of-your-pants a-la C &co. Haskell at least has the good grace to firewall any imperative crap so that the remainder of the…
By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? I think a more reasonable position allows for gradations of reliability, and appreciates the benefits of encouraging pure computations while allowing room for judicious use of benevolent side effects.
> they are already evolutionary dead-ends
That is patently false, imo. OCaml has a number of interesting features which most statically typed FP languages are yet to explore (e.g., polymorphic variants, (typed) named and optional arguments, first-class modules, binding operators). More to the point, ongoing development on a novel approach to multi-core, native support for algebraic effects, and modular implicits, testify to it being a live evolutionary branch. OCaml aside, innovative languages and approaches like like F, 1Ml, Frank, BER MetaOcaml, and Rust seem to give clear evidence that we still have much to learn from impure* dialects of ML.
Earlier quoted context omitted.
Rust eases newcomers into the language a lot more than C++ does. As there are plenty of novices learning C++ as their first(!) programming language, I'm not sure why newcomers would be expected to have more of an issue with Rust
I'd consider C++ as the worst of the worst when it comes to ease of entry. Compared to, say Javascript, Ruby, or Go, Rust has a secondary set of rules that programmers have to learn before they can even do the most simple things. As an experienced programmer, I look at most Rust code with bewilderment. This is after a week of studying the language. I can look at Python and instantly understand what's happening, witho…
The rules are not that hard if you're somewhat familiar with the constraints of functional programming. Rust requires you not to rely on shared, mutable state, unless specifically enabled - thus, by default, you're essentially writing FP code using a 'procedural' paradigm and syntax.
It is also possible to do "quick, exploratory" programming in Rust; it just requires somewhat liberal use of language facilities such as .clone() and RefCell, to specify things that would mostly be implicit in other memory-safe languages. (And because these somewhat problematic features are so clearly marked in the resulting code, it becomes fairly easy to directly refactor it into better-performing, idiomatic Rust.)
Not at CERN, but it used to be the case. It's C++ now.
> It turns out that FORTRAN is a very good match for the way physicists think about their work
I don't even know what this means and I have a PhD in Physics.
> You simply specify what fields you have and what pattern they are written in and the computer takes care of all the reading and writing for you
This is possible in any language with decent reflection.
> and layers upon layers of unnecessary complexity
None of the complexity in C++ is unnecessary. There were, as there are always, trade-offs.
> Go was created explicitly to replace C++, it turned out that the programmers who love C++
IMHO, this is regurgitated nonsense from Rob Pike. What I got from what he wrote on the subject is that he doesn't grok C++ at all. If he did, he wouldn't be surprised that C++ developers didn't flock to Go.
> efficient development of efficient programs
I'm not aware of Go programs that are particularly efficient. I'd also argue against "efficient development".
> there is an elegant practical solution in Go
Elegance is in the eye of the beholder. I don't think pretty much anything in Go is elegant nor possible to be because of the lack of generics. It forces people to write for loops, which is just... mind boggling to me. That alone makes me wonder what kind of Python devs are taking it up.