Ask HN: What's the most underrated programming language?
168 comments
Java is really underrated. It is popular but it isn't thought of as powerful or cool as compared to python, haskell etc.. I disagree.
a. Object oriented code done right is the best way to handle production code.
b. Java has introduced streams, lambdas etc.. has any other language shown this type of adaptation to times ?
c. Python, Ruby etc.. don't have equivalent performance
d. c++ obviously beats it on performance but I know the pain of porting c++ code
e. Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
f. Java made a really good comeback with Android
So the new kids in the block might not like Java because it isn't cool but Java has stood the test of time.
a. Object oriented code done right is the best way to handle production code.
b. Java has introduced streams, lambdas etc.. has any other language shown this type of adaptation to times ?
c. Python, Ruby etc.. don't have equivalent performance
d. c++ obviously beats it on performance but I know the pain of porting c++ code
e. Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
f. Java made a really good comeback with Android
So the new kids in the block might not like Java because it isn't cool but Java has stood the test of time.
Java's main strength is the jvm.
C# as a language is superior to Java in pretty much every meaningful way.
All the things you mention about Java were done in C# and much more elegantly.
Where Java shines is not the language but the runtime behind it.
All the things you mention about Java were done in C# and much more elegantly.
Where Java shines is not the language but the runtime behind it.
With C#, it's not _just_ the language. Typically, you'll pay for licensing costs of hosting the infrastructure required to run production grade C# applications. With Java, you can use open source infrastructure and servers.
That is only if you use C# with .Net framework over .Net core
.NET Core is still pretty immature though. The quantity of third party libraries that support it is tiny in comparison to what you get with Java.
From what I can tell it is mature enough for stack overflow to use it
I was referring more to the overall ecosystem than the core platform, which is solid. Stack Overflow uses Dapper rather than Entity Framework, and that alone makes transitioning much easier. EF on .NET Core still just isn’t as good, and the third party library support isn’t as good either. For most people, I don’t really think moving to Core is quite worth it yet.
Stackoverflow runs on .NET Core? That's news to me.
But C# is still a better language that isn't as widely used (therefore it's underrated). And that's what we're talking about.
In addition to the jvm, Java's comprehensive system of libraries is simply not matched by .NET in my experience.
I really wish C# had more battle tested linux usage. I really love that language.
Runtime, and community.
I've been banging this drum lately on HN too. Spring Boot makes Java fast, easy, and simple. Yes, you still have to install a JVM on your image, but there are plenty of management script out there to get a container or VPS running.
For people out there that look at all those getters and setters with contempt: you don't need them for your JSON objects. Just use public. The frameworks will still serialize and deserialize without issue. Use JSON annotations to define what a valid message is. Yes, you'll need a mapping layer between your JSON/inbound messages and your domain, but you need that anyway, otherwise your API is brittle.
JPA + Spring can lead to fast DB code and development time that rivals NoSQL with Postgres. You can have it autogenerate the DB during dev time with each boot, then create Liquibase migration documents for true devops stability.
After working with Go for a month, I really think Java just does things right. Servlet API is simple. Spring makes it easier. Transactional management + AOP is wonderful. So many cross-cutting concerns allow you to properly encapsulate and apply the logic in a few AOP. You just can't do that with GO without a lot of compiler work.
For people out there that look at all those getters and setters with contempt: you don't need them for your JSON objects. Just use public. The frameworks will still serialize and deserialize without issue. Use JSON annotations to define what a valid message is. Yes, you'll need a mapping layer between your JSON/inbound messages and your domain, but you need that anyway, otherwise your API is brittle.
JPA + Spring can lead to fast DB code and development time that rivals NoSQL with Postgres. You can have it autogenerate the DB during dev time with each boot, then create Liquibase migration documents for true devops stability.
After working with Go for a month, I really think Java just does things right. Servlet API is simple. Spring makes it easier. Transactional management + AOP is wonderful. So many cross-cutting concerns allow you to properly encapsulate and apply the logic in a few AOP. You just can't do that with GO without a lot of compiler work.
Personally I've had the exact opposite experience with Spring Boot. To me it feels like they've basically had to metaprogram their way out of the limitations of both the language and the underlying APIs which are extremely verbose and obtuse. Every time Spring makes something more convenient, it also removes some static guarantees. Dependency injection issues fail at runtime instead of compile time, but that's not anywhere near the worst of it.
Autoconfiguration in particular seems nice at first but can cause all sorts of weird issues. I once had a situation where we added RabbitMQ, and some other JAR started trying to bind to a queue that didn't exist, but the framework was swallowing that exception and it took hours of screwing around in the debugger to figure out what was going on. That sort of thing simply doesn't happen with Go in my experience. Or probably Dropwizard, honestly.
Autoconfiguration in particular seems nice at first but can cause all sorts of weird issues. I once had a situation where we added RabbitMQ, and some other JAR started trying to bind to a queue that didn't exist, but the framework was swallowing that exception and it took hours of screwing around in the debugger to figure out what was going on. That sort of thing simply doesn't happen with Go in my experience. Or probably Dropwizard, honestly.
> Java has introduced streams, lambdas etc.. has any other language shown this type of adaptation to times?
Well, Lisp added CLOS, which was a huge adaptation to the rise of OOP. It also originated lambdas. I don't know if streams originated in Lisp, or if they were an adaptation from another language.
> Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
That's why I prefer a homoïconic language: I can write & generate the boilerplate in the language itself.
> Java made a really good comeback with Android
I don't know if that's true so much as there really aren't good options to Java on Android. I'd give my eye teeth for a good Go GUI SDK for Android, for example.
Well, Lisp added CLOS, which was a huge adaptation to the rise of OOP. It also originated lambdas. I don't know if streams originated in Lisp, or if they were an adaptation from another language.
> Most of the boilerplate code is either auto-generated or you can use Lombok type framework to generate them for you
That's why I prefer a homoïconic language: I can write & generate the boilerplate in the language itself.
> Java made a really good comeback with Android
I don't know if that's true so much as there really aren't good options to Java on Android. I'd give my eye teeth for a good Go GUI SDK for Android, for example.
Agree 100% if you're implying Common LISP/CLOS as the most underrated.... it's fun to show people examples from the Art of the Metaobject Protocol and watch their heads explode :-)
b. Java has introduced streams, lambdas etc.. has any other language shown this type of adaptation to times ?
"Adaption to times"? Lambdas are older than Java itself. It was outdated in v1.
"Adaption to times"? Lambdas are older than Java itself. It was outdated in v1.
I don't think lack of providing a feature because its exists makes a language out of date.
I think OPs point was that the language has evolved more dramatically than other popularly adopted languages.
I think OPs point was that the language has evolved more dramatically than other popularly adopted languages.
The best answer to your point b is C++. It's shown a ton of adaptation to the times. Almost to a crazy extent as you see tons of new features hit in each standards revision (C++11, 14, 17, etc). To me, it keeps up more quickly than Java.
Maybe that's because it was so far behind to start with? And I'm finding it hard to keep up with all the changes. Some things just seem like they're awkwardly bolted on, like Lambdas.
Is it though? I work in the Danish public sector which is mostly windows based enterprise and 80-90% of our infrastructure runs on JAVA with no change in sight. Hell, most influential people will straight out laugh at the notion of JAVA losing steam. It did dip for a while some years back, but these days it’s frankly the strongest I’ve ever seen it.
Of course it’s not popular for hobby projects, startups, academia or data science, but those fields are frankly dwarfed by enterprise on the job market.
C# has a stronger hold in the private sector, but scince most of the public software is produced by the private sector even there JAVA runs strong.
Of course it’s not popular for hobby projects, startups, academia or data science, but those fields are frankly dwarfed by enterprise on the job market.
C# has a stronger hold in the private sector, but scince most of the public software is produced by the private sector even there JAVA runs strong.
Kotlin will get you these without the:
Foo foo = new Foo();
> Foo foo = new Foo();
The Golang FAQ calls that stuttering; good term, I thought.
https://golang.org/doc/faq
See section:
What are the guiding principles in the design?
"Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct."
The Golang FAQ calls that stuttering; good term, I thought.
https://golang.org/doc/faq
See section:
What are the guiding principles in the design?
"Stuttering (foo.Foo* myFoo = new(foo.Foo)) is reduced by simple type derivation using the := declare-and-initialize construct."
Or my favorite, for declaring/initializing static members:
Foo::Bar *Foo::foobar = new Foo::Bar(Foo::Bar::FOOBARENUMVALUE);
Foo::Bar *Foo::foobar = new Foo::Bar(Foo::Bar::FOOBARENUMVALUE);
Kotlin will be huge once HelloWorld takes less then 8sec to compile
? Instantaneous on my box. Maybe time for a pentium overdrive. ;-)
Java has many features that are amazing for larger projects:
* Instant recompilation
* One string type
* One error handling system
* Capitalized identifier = class name = file name = imported name
* English names for everything and no operator overloading
All these are ignored by e.g. Haskell or Rust.
* Instant recompilation
* One string type
* One error handling system
* Capitalized identifier = class name = file name = imported name
* English names for everything and no operator overloading
All these are ignored by e.g. Haskell or Rust.
> English names for everything
You mean like, AbstractSingletonProxyFactoryBean? Sure, it's English, but when you end up with a project with that many layers of needless abstraction, it's not going to be easily and quickly comprehensible by anyone who isn't already familiar with it.
You mean like, AbstractSingletonProxyFactoryBean? Sure, it's English, but when you end up with a project with that many layers of needless abstraction, it's not going to be easily and quickly comprehensible by anyone who isn't already familiar with it.
Yeah, that's a fair point.
I think factories and beans are a sign that object construction in Java is a mess. In the applications I work with, most calls to "new" are dealing with data structures (lists, maps, protocol buffers), and behavior-heavy business objects are a mostly static call graph. Not sure if there's a name for this pattern though.
I think factories and beans are a sign that object construction in Java is a mess. In the applications I work with, most calls to "new" are dealing with data structures (lists, maps, protocol buffers), and behavior-heavy business objects are a mostly static call graph. Not sure if there's a name for this pattern though.
I agree with the answer of Java, but saying "object oriented [...] is the best way", "has any other language shown this type of adaptation to times", "etc.. don't have equivalent performance", etc is going to get you some flak. I don't agree with any of those statements.
As someone who has done a lot of Scala and Kotlin, I appreciate Java because I can anticipate the bytecode that will be generated. This is important to me on low-level JVM projects (profilers, fuzzers, etc).
As someone who has done a lot of Scala and Kotlin, I appreciate Java because I can anticipate the bytecode that will be generated. This is important to me on low-level JVM projects (profilers, fuzzers, etc).
> has any other language shown this type of adaptation to times
C#
C#
> Java
> Object oriented code done right
Pick one.
But in all seriousness, Java is definitely underrated amongst many who are working with the trendier technologies. It's not perfect, but it gets the job done, and it's a solid platform with phenomenal tooling.
I don't think "Python, Ruby etc. don't have equivalent performance" is actually very important though. In practice, the availability of developers in a particular market, legacy code, and static typing & refactoring tools probably have much more to do with Java's success than performance.
> Object oriented code done right
Pick one.
But in all seriousness, Java is definitely underrated amongst many who are working with the trendier technologies. It's not perfect, but it gets the job done, and it's a solid platform with phenomenal tooling.
I don't think "Python, Ruby etc. don't have equivalent performance" is actually very important though. In practice, the availability of developers in a particular market, legacy code, and static typing & refactoring tools probably have much more to do with Java's success than performance.
Well C#? (and Android through Xamarin but I didnt use it so...)
Not underrated, but F# gets a lot of flack for what has proven an extremely usable and productive language.
* It is functional and succinct by default, but allows you to go mutable and fast when needed (see the alioth benchmarks).
* Open source culture
* The tooling (thanks to kcieslak and others) is fantastic
* Web story is covered well by suave/giraffe on the backend, with fable-elmish as a personal favorite if I need complex front-end functionality (most stuff I have is just regular pages though).
* Mobile story through Xamarin(Forms is not my favorite, but Native works fine) or Fable
* To mention javascript again, I think Fable has a ton of well thought out features compared to other transpiled languages
* Testing via expecto (and just github.com/haf in general)
* A whole wealth of libraries through .net integration
* I can compile a binary to execute on linux for easy deployments, or target osx to create convenience command line applications for my coworkers
There are some negatives (some C# interop gets inelegant, some tooling is left to the community as a responsibility, other minor things), but overall it has all of the important things.
* It is functional and succinct by default, but allows you to go mutable and fast when needed (see the alioth benchmarks).
* Open source culture
* The tooling (thanks to kcieslak and others) is fantastic
* Web story is covered well by suave/giraffe on the backend, with fable-elmish as a personal favorite if I need complex front-end functionality (most stuff I have is just regular pages though).
* Mobile story through Xamarin(Forms is not my favorite, but Native works fine) or Fable
* To mention javascript again, I think Fable has a ton of well thought out features compared to other transpiled languages
* Testing via expecto (and just github.com/haf in general)
* A whole wealth of libraries through .net integration
* I can compile a binary to execute on linux for easy deployments, or target osx to create convenience command line applications for my coworkers
There are some negatives (some C# interop gets inelegant, some tooling is left to the community as a responsibility, other minor things), but overall it has all of the important things.
Nim. I understand some reasons for this, as I didn't pay attention to it very much for awhile myself. I think it's only the last year or two that it's reached maturity. Its primary alternatives also have the advantage of huge existing resource bases.
I'm someone who thinks there is room for lots of good languages, and each has its role, so I don't think languages should be pitted against one another necessarily.
However, with Nim you have something very similar to Python in its expressivity, but with performance comparable to things like Rust and C++. The metaprogramming is very well done as far as I've seen, and it seems very well thought out. It also has solid, useful compilation targets.
It just seems like the whole package for a lot of use cases and I'm not sure why it's not getting a lot more attention.
I'm someone who thinks there is room for lots of good languages, and each has its role, so I don't think languages should be pitted against one another necessarily.
However, with Nim you have something very similar to Python in its expressivity, but with performance comparable to things like Rust and C++. The metaprogramming is very well done as far as I've seen, and it seems very well thought out. It also has solid, useful compilation targets.
It just seems like the whole package for a lot of use cases and I'm not sure why it's not getting a lot more attention.
I’ve used nim in production and I even wrote a very small part of the language itself; and it’s great in many ways, but unfortunately it lacks taste. When a language gets that complex it needs to be consistent and it needs to exhaustively cover use cases and nim is obviously better than C, no question, but it’s no Ruby. Maybe it will be one day, but for now having a smaller amount of features like Rust allows for a cleaner more cohesive picture and building on top of that is easier. Though I hate Rust’s syntax. Crystal looked promising for a while, but dev there is slow.
I still wish the coffeescript model had worked out where we could view or think about languages differently and compile them to a common one. But unfortunately it doesn’t work without a great deal of effort.
I still wish the coffeescript model had worked out where we could view or think about languages differently and compile them to a common one. But unfortunately it doesn’t work without a great deal of effort.
>unfortunately it lacks taste
Taste is subjective ...
De gustibus non est disputandum:
https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu...
... so it is almost as though by default, you have to explain/justify your opinion on this :)
Taste is subjective ...
De gustibus non est disputandum:
https://en.wikipedia.org/wiki/De_gustibus_non_est_disputandu...
... so it is almost as though by default, you have to explain/justify your opinion on this :)
> unfortunately it lacks taste
Could you expand on that? I always thought the core nim language was fine. But, I've also come to the conclusion that the few libraries I've used that were written in nim are of poor quality. Is that a function of the language? The community? Or both? I have no idea.
Could you expand on that? I always thought the core nim language was fine. But, I've also come to the conclusion that the few libraries I've used that were written in nim are of poor quality. Is that a function of the language? The community? Or both? I have no idea.
Multiple and optional GC methods, exception tracking, effect system, ability to generate C and JavaScript, C-to-Nim translation and wrapper generation.
Nim is underrated indeed.
Nim is underrated indeed.
D.
It really is a great successor to C++, with lots of new ideas taken from other languages too, and some very insightful language designers. I wish people would give it more of a chance and not stop at "it has a GC" and decide that this makes the whole language worthless.
It's been around for a while but hasn't gotten popular yet. I don't know if the weird license for the reference compiler is what slowed down adoption. At least for me, that's why I was hesitant to commit to D. After the license change, I've had so much fun with it.
It really is a great successor to C++, with lots of new ideas taken from other languages too, and some very insightful language designers. I wish people would give it more of a chance and not stop at "it has a GC" and decide that this makes the whole language worthless.
It's been around for a while but hasn't gotten popular yet. I don't know if the weird license for the reference compiler is what slowed down adoption. At least for me, that's why I was hesitant to commit to D. After the license change, I've had so much fun with it.
>I wish people would give it more of a chance and not stop at "it has a GC" and decide that this makes the whole language worthless.
Seriously! I've never seen anyone complain that e.g. Go has a garbage collector, and Go's is not even optional. The only thing Go has over D is a large corporate sponsor.
Seriously! I've never seen anyone complain that e.g. Go has a garbage collector, and Go's is not even optional. The only thing Go has over D is a large corporate sponsor.
That's mostly because the Go folk stopped calling Go a systems language. And they did that pretty quickly after public launch precisely because of all the people pointing out it had a non-optional GC.
The only thing Go has over D is:
- predictable release process
- predictable language development
- predictable changes between versions
- clear direction
- no competing and non-interoperable standard libraries
- a backwards incompatible version 2 does not come out 6 months after version 1.0 deprecating it.
Oh. Wait. That wasn't just an "only" thing.
- predictable release process
- predictable language development
- predictable changes between versions
- clear direction
- no competing and non-interoperable standard libraries
- a backwards incompatible version 2 does not come out 6 months after version 1.0 deprecating it.
Oh. Wait. That wasn't just an "only" thing.
I argue it was the collection wars and few new books after the dust settled. You can't have the community split over which List implementation to use. Especially now when picking one side locks you into for the rest of that projects life and they are incompatible with the other collections.
I'm going to riff on what Null-Set said about Ada, which people like to criticize for its complexity but which actually solved a lot of hard problems in very creditable fashion for its day. The complexity complaints are a joke, considering that that both Java and C++ have since become more complex than Ada ever was by trying to solve some of the same problems -and in C++'s case largely failing. If Ada (or its relative Modula) were introduced today, it would seem like a breath of fresh air compared to those two.
Special runner-up: MOOcode, the native language of LambdaMOO. Still one of the most coherent and pleasant object-oriented languages I've used. It's especially notable for its "code runs as author not invoker" protection model and call-stack introspection. People could learn a lot from that.
My first thought was Nim, and o2348diuu already explained why. Second thought was Lua, but a couple of people beat me to that. Haskell and Elixir are definitely not underrated. They're underused, certainly, but that's not the same thing and IMO Haskell is often overrated.
Special runner-up: MOOcode, the native language of LambdaMOO. Still one of the most coherent and pleasant object-oriented languages I've used. It's especially notable for its "code runs as author not invoker" protection model and call-stack introspection. People could learn a lot from that.
My first thought was Nim, and o2348diuu already explained why. Second thought was Lua, but a couple of people beat me to that. Haskell and Elixir are definitely not underrated. They're underused, certainly, but that's not the same thing and IMO Haskell is often overrated.
Can we call SQL a programming language, or no? (I was trying to think of someone who's been around for a while, but maybe doesn't receive his just due.)
SQL seems to power nearly everything at some level, has much code written in other languages for the sole purpose of interfacing with it (for better or worse), has inspired other concepts and technologies (even as they are defined against it as what they are not), etc.
I don't think anybody mentioned C yet either, another foundational case…
SQL seems to power nearly everything at some level, has much code written in other languages for the sole purpose of interfacing with it (for better or worse), has inspired other concepts and technologies (even as they are defined against it as what they are not), etc.
I don't think anybody mentioned C yet either, another foundational case…
If SQL deserves consideration for being "underrated", Datalog certainly does.
Compared to SQL, Datalog makes recursive queries very natural[1], making it good for manipulating graph-like structures. For example, here's reachability in a graph:
Variants of Datalog pop up in unexpected places. Datalog dialects are often used for implementing code analysers (e.g. Semmle). Datomic's product is a variety of Datalog with S-expression syntax. UC Berkeley has a Datalog-based research language called bloom (http://bloom-lang.net/faq/) aimed at implemented distributed systems. Datalog was also an influence on the recently-shuttered Eve (http://witheve.com/) project.
In its original form Datalog lacks aggregations, which is probably a big part of why it didn't catch on - aggregations are important! Still, some Datalog implementations add support for aggregations. Unlike SQL, Datalog never really became a standard; more an academic ideal than a practical tool. I think this is a shame.
While Datalog doesn't have a canonical practical implementation, in terms of impact on how people think about data query languages, I think it's an academic gem.
[1] SQL has recursive queries ("Recursive CTEs"), but they're neither widely used nor particularly well-supported in most SQL implementations - they're basically tacked on. This is partly because they're hard to optimize due to a lack of restrictions; with Recursive CTEs, SQL is Turing-complete. Datalog deliberately isn't, and there's a large literature on optimizing evaluation of recursive Datalog.
Compared to SQL, Datalog makes recursive queries very natural[1], making it good for manipulating graph-like structures. For example, here's reachability in a graph:
reaches(X,Y) :- edge(X,Y).
reaches(X,Z) :- edge(X,Y), reaches(Y,Z).
Variants of Datalog pop up in unexpected places. Datalog dialects are often used for implementing code analysers (e.g. Semmle). Datomic's product is a variety of Datalog with S-expression syntax. UC Berkeley has a Datalog-based research language called bloom (http://bloom-lang.net/faq/) aimed at implemented distributed systems. Datalog was also an influence on the recently-shuttered Eve (http://witheve.com/) project.
In its original form Datalog lacks aggregations, which is probably a big part of why it didn't catch on - aggregations are important! Still, some Datalog implementations add support for aggregations. Unlike SQL, Datalog never really became a standard; more an academic ideal than a practical tool. I think this is a shame.
While Datalog doesn't have a canonical practical implementation, in terms of impact on how people think about data query languages, I think it's an academic gem.
[1] SQL has recursive queries ("Recursive CTEs"), but they're neither widely used nor particularly well-supported in most SQL implementations - they're basically tacked on. This is partly because they're hard to optimize due to a lack of restrictions; with Recursive CTEs, SQL is Turing-complete. Datalog deliberately isn't, and there's a large literature on optimizing evaluation of recursive Datalog.
Where SQL excels is working on vast batches of data without using loops. Once you can think in terms of datasets, it becomes very logical to process it all at once.
Nobody needs to mention C because it is definitely not underrated - it's earned its reputation and is respected/feared by developers everywhere!
Nobody needs to mention C because it is definitely not underrated - it's earned its reputation and is respected/feared by developers everywhere!
[deleted]
Object Pascal (FreePascal/Lazarus/Delphi)
Many, many production applications have been written using these languages/environments, but the language has fallen out of favor since the early 2000s.
- Code is easy to read and understand, and you can get a new developer up to speed quickly
- Can be used as a high-level language, a low-level language (you can even include in-line assembler), or both
- Blazing fast compilation
- Statically-typed, and includes classes, records (structs), reference-counted interfaces and strings
- Lots of implementations and platforms
Many, many production applications have been written using these languages/environments, but the language has fallen out of favor since the early 2000s.
- Code is easy to read and understand, and you can get a new developer up to speed quickly
- Can be used as a high-level language, a low-level language (you can even include in-line assembler), or both
- Blazing fast compilation
- Statically-typed, and includes classes, records (structs), reference-counted interfaces and strings
- Lots of implementations and platforms
I started picking Object Pascal up (FreePascal & Delphi varieties) and was amazed by it. It is rather simple and compiles to native code. Not only that, you can create mobile apps (and even macOS apps) with both Delphi and FreePascal.
I'm glad that you're liking it - it's a very "approachable" language. I discovered it 20+ years ago, and never looked back. I've written all sorts of software with it: manufacturing order entry configurators, payroll software, application servers, database engines/servers, ODBC drivers, .NET data providers, compilers, and a web application development IDE.
If you're looking to do web development (browser) with Object Pascal, then here's a shameless plug for our product, Elevate Web Builder:
https://www.elevatesoft.com/products?category=ewb&type=web
If you're looking to do web development (browser) with Object Pascal, then here's a shameless plug for our product, Elevate Web Builder:
https://www.elevatesoft.com/products?category=ewb&type=web
I spent nights on Pascal (Borland) coding a Conway's game of life on an IBM PC as a student. One of fondest memories from 1990 I think.
It was a great language, the first real one I learned.
It was a great language, the first real one I learned.
There once was a language that compiled in milliseconds - you pressed a single button and your changes were instantly in front of you. What's more a clever separation of data and code meant that this instant reload would show your newly compiled app with your data still in place, and you looking at the same screen as before, exactly where you had left it, except powered by your new code.
This separation between data and code also enabled trivial scaling for huge system, as well as the opposite - hundreds of apps, each belonging to a different customer could share the same system - decades before docker or k8 was born.
This language was written when Objects were the only thing people talked about. In a counter-cultural move, the language's author wrote the entire standard library as only functions. The language could be easily learned - just look at the list of functions for the one that does what you want.
It's cross platform - the user interfaces you build work on all platforms with a single codebase.
Its combination of scaling, quick development iterations, and ease of use powered the rise of fourth largest tech company in the world today. In fact, just a single app written in this language has more than a billion people using it every day.
Darkly, however, the name of this language may not be spoken here. Even by praising it obliquely, I risk censure, and my perceived value of my work being cut by eighty percent in penalty.
I will not name it.
This separation between data and code also enabled trivial scaling for huge system, as well as the opposite - hundreds of apps, each belonging to a different customer could share the same system - decades before docker or k8 was born.
This language was written when Objects were the only thing people talked about. In a counter-cultural move, the language's author wrote the entire standard library as only functions. The language could be easily learned - just look at the list of functions for the one that does what you want.
It's cross platform - the user interfaces you build work on all platforms with a single codebase.
Its combination of scaling, quick development iterations, and ease of use powered the rise of fourth largest tech company in the world today. In fact, just a single app written in this language has more than a billion people using it every day.
Darkly, however, the name of this language may not be spoken here. Even by praising it obliquely, I risk censure, and my perceived value of my work being cut by eighty percent in penalty.
I will not name it.
The language is PHP.
The instant reload and not losing your place is because changes to the server do not affect what's in the browser.
Customers sharing a system works because you can just have directories of PHP files.
PHP was developed without any kind of object system.
PHP is completely cross-platform because the UI is in the browser.
PHP powered Facebook.
PHP has a very poor reputation here.
PHP is in the top 10 tags on StackOverflow.
The instant reload and not losing your place is because changes to the server do not affect what's in the browser.
Customers sharing a system works because you can just have directories of PHP files.
PHP was developed without any kind of object system.
PHP is completely cross-platform because the UI is in the browser.
PHP powered Facebook.
PHP has a very poor reputation here.
PHP is in the top 10 tags on StackOverflow.
> The instant reload and not losing your place is because changes to the server do not affect what's in the browser.
Nitpick:
That's a HTTP 'REST' feature, surely?
The feature then is that PHP doesn't chuck out your sessions because the code has changed. But then other platforms can do this.
Nitpick:
That's a HTTP 'REST' feature, surely?
The feature then is that PHP doesn't chuck out your sessions because the code has changed. But then other platforms can do this.
Bingo! You got it!
PHP 4, maybe? My experience with PHP 5+ has not been any of the things you mention.
Most PHP frameworks these days are a horror show of overcomplexity, precisely because they are trying to write Java in a language that is not Java.
In my crotchety, old man opinion, people have been trying very hard to make PHP like a blub, overly verbose language, and trying to hide the things that made it great.
In my crotchety, old man opinion, people have been trying very hard to make PHP like a blub, overly verbose language, and trying to hide the things that made it great.
What kind of things make it great? I only see downsides or at the very least poorly implemented upsides that most other languages only have.
-> compiled in milliseconds
-> separation between data and code
-> trivial scaling for huge system
-> hundreds of apps, each belonging to a different customer could share the same system
-> decades before docker
-> standard library as only functions.
-> It's cross platform - the user interfaces you build work on all platforms with a single codebase.
-> this language has more than a billion people using it every day.
-> the name of this language may not be spoken here
can only be PHP
-> separation between data and code
-> trivial scaling for huge system
-> hundreds of apps, each belonging to a different customer could share the same system
-> decades before docker
-> standard library as only functions.
-> It's cross platform - the user interfaces you build work on all platforms with a single codebase.
-> this language has more than a billion people using it every day.
-> the name of this language may not be spoken here
can only be PHP
erlang.
Functional. Cross-platform (it has it's own vm, of course), instant deployment and hot rollback (via a/b images), etc.
Your puzzle-as-description was very cleverly written and an enjoyable exercise! Bravo!
Functional. Cross-platform (it has it's own vm, of course), instant deployment and hot rollback (via a/b images), etc.
Your puzzle-as-description was very cleverly written and an enjoyable exercise! Bravo!
HN doesn't dislike Erlang. You only see unequivocal detestation for PHP and VB.
My guess would be PHP although there's a reasonable argument that most of the Fortune 500 runs on VB.
My guess would be PHP although there's a reasonable argument that most of the Fortune 500 runs on VB.
If anything Erlang has been getting more attention recently (usually in the form of Elixir/Phoenix, but still).
Cool guess! But that's still not it!
(Though I have used this language's hot reloading features to win a faux stock market trading war, by being able to swap in newly written market making strategies on the fly)
Here’s a hint - its been around since before flip phones, and has been a top ten language on stack overflow since the site was started.
(Though I have used this language's hot reloading features to win a faux stock market trading war, by being able to swap in newly written market making strategies on the fly)
Here’s a hint - its been around since before flip phones, and has been a top ten language on stack overflow since the site was started.
Ok top 10 languages 2017 for SO are:
JavaScript SQL Java C# Python PHP C++ C TypeScript Ruby
The data reload in place has thrown me. I am not sure any of the above do this. Maybe I am wrong though.
JavaScript SQL Java C# Python PHP C++ C TypeScript Ruby
The data reload in place has thrown me. I am not sure any of the above do this. Maybe I am wrong though.
Is it Visual Basic ? VB is taboo in many tech communities.
Sounds a bit like Javascript, am I right?
[deleted]
I think it's Haskell.
I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever a hard language design problem comes up in any new language, Haskell has solved it more than 2 decades ago.
The ecosystem (Hackage etc) is pretty bad though.
I know sometimes it gets some hype but Haskell and its ilk is just so above the quality of any other language it's mind bending. Whenever a hard language design problem comes up in any new language, Haskell has solved it more than 2 decades ago.
The ecosystem (Hackage etc) is pretty bad though.
why is the ecosystem bad? While no metrics for "underrated" are proposed here, I would say, empirically Haskell does not seem like your go-to language if you want to develop useful and maintainable software.
Sounds a bit like a chicken and egg problem.
It's not like the ecosystem is non-existent. At all. Only are most libraries really hard to use (IMHO), and they don't compose well (too many complicated types), have terrible compile times...
The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
The language might be elegant at the core, but it's too far removed from reality (efficiency on real computers is super hard to control from Haskell) and it's far too focused on types (which, while they catch some errors, slow development down, and encourage unnecessary complexity ("easier" and "more type-safe")). After all, it's an academic language.
But every language has that problem, and most mainstream languages overcome it. Why not Haskell? From an interested outsider's perspective, it seems like the community is focused more on ideas than on solutions. For me, this makes it endlessly intriguing (the ideas are interesting and often mind-bending) but not very useful (the solutions for the things I want to do appear under-developed).
Yeah. Haskell is so imba people don't believe you when you tell them :)
It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating.
(...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)
It's understandable to show skepticism about "the new shiny thing" (although Haskell is > 30 years old) because most new shiny things turn out to be not that great after all. I've been struggling to communicate the "no, but really" distinction without much success to other people and it's frustrating.
(...for purely egoistical reasons though, I don't really care what people are using as long as I get to use a sane language in my day job, which is currently not the case.)
I agree, I think the diagram on page 12(?) of http://dev.stephendiehl.com/nearfuture.pdf sums it up nicely.
If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.
If you think this is smugness, look into it. The features that come up with GHC extensions have no equivalent in other languages, because the commonly used stuff in Haskell so far ahead.
Haskell was the first language I learned that I actually loved in an irrational way. I consider myself to be a 3/10 haskeller because I've written a couple thousands lines, but never built anything "real" with it. But it is just such a beautiful experience to be writing it. It feels very much like a pit of success.
Stack (haskellstack.org) has pretty much solved the problems associated with building directly from Hackage though. The biggest pain when developing Haskell code continues to be the lack of good debugging facilities.
I am not really well versed in Haskell debugging, but a thought..
Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time)..
What would debugging look like if we looked at it from the functional perspective?
For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.
Current debuggers are built around very imperative notion of program state. I have breakpoints, I can look at variables (state in a given time)..
What would debugging look like if we looked at it from the functional perspective?
For example, execution "filters" instead of breakpoints. What happens if this function receives value that satisfies certain condition? Instead of variable watches, give out a breakdown of the data passed in and out from the function. Etc.
Haskell hasn't solved GUI design, and it probably never will unless it comes up with a better way of modeling mutable state.
What about FRP? I haven't tried it but in theory it very much reminds me of Qt (which I think today would be called "reactive"), and the Qt was probably the most pleasurable GUI toolkit to write in.
I think this has more to do with lack of polished UI editors (build tools) than with the language.
I think this has more to do with lack of polished UI editors (build tools) than with the language.
All GUIs are "reactive", because all UIs (mechanical, analog, digital, whatever...) are abstracted state machines. And state machines are defined by the following formulate: state0 + event = effect + state1. You can't design a GUI without having a state and reacting to events.
One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.
One could easily say that Qt was pleasurable because it was a well designed object-oriented and inheritance based toolkit. I have my reasons to believe this is objectively better within the context of UI design, and that pure functional programming in GUI design will never break out of it's magnificently tiny niche, but I'm not gonna go into that here. I'd rather just point out that some shared theoretical idea behind both Qt and Haskell UI design doesn't in any way imply that Qt's success could be Haskell's as well. Only Haskell programmers, working in Haskell code, could prove that idea. And if it really is that great, then surely they could do it.
that's so true. I woulnd't call it underrated though as it's pretty much one of the defacto starting programming languages universities use.
Where are you from that this is true? England? I think very few universities in the USA use Haskell in intro classes.
Wolfram Language / Mathematica. Probably not "underrated" since it is backed by an entire company with the sole purpose of developing it -- but as a programming language it is absolutely underappreciated.
* Essentially a Lisp. Data and program can be freely interchanged and is frequently done in completely normal code.
* The most impressive "standard" "library" in existence: everything from symbolic calculus, machine learning, UI building, graphics, signal processing, data import and export, foreign function interfaces and it just goes on and on.
* Incredible attention to consistency and interoperability. Everything behaves in predictable and orthogonal fashions. Right from the low-level pattern matching up to interacting with the build in database.
* The best documentation of any programming language. Nothing compares even slightly in breath, friendliness, consistency.
* Essentially a Lisp. Data and program can be freely interchanged and is frequently done in completely normal code.
* The most impressive "standard" "library" in existence: everything from symbolic calculus, machine learning, UI building, graphics, signal processing, data import and export, foreign function interfaces and it just goes on and on.
* Incredible attention to consistency and interoperability. Everything behaves in predictable and orthogonal fashions. Right from the low-level pattern matching up to interacting with the build in database.
* The best documentation of any programming language. Nothing compares even slightly in breath, friendliness, consistency.
I'll say PHP because it's so underrated that I'm somewhat afraid to mention it here.
It's far from the most sane language I've ever used, and as much as I love it, I'll admit there are parts of the syntax that straight up hurt my soul. Yet, despite all the drawbacks, if I need to write something fast, PHP and a micro-framework (I like Slim) is always my first choice.
It's far from the most sane language I've ever used, and as much as I love it, I'll admit there are parts of the syntax that straight up hurt my soul. Yet, despite all the drawbacks, if I need to write something fast, PHP and a micro-framework (I like Slim) is always my first choice.
Having worked in lot of languages (most recently — Go), I can say PHP by far is the best to get the job done especially when it comes to web related stuff.
PHP let's you be what you want to be. If you are an architect with years of experience building a suite of microservices where you would want to use lot of bells and whistles, testing, dependency management, etc. do it. If you are a novice programmer looking to create your wedding website and have a simple contact form, do that as well!
Best part, each request is a clean start and independent.
PHP let's you be what you want to be. If you are an architect with years of experience building a suite of microservices where you would want to use lot of bells and whistles, testing, dependency management, etc. do it. If you are a novice programmer looking to create your wedding website and have a simple contact form, do that as well!
Best part, each request is a clean start and independent.
I always did like PHP for quick, small things. It was convenient. That was back in the PHP 4 days, though. It all went downhill after they added OOP classes in PHP 5. What is considered best practices among the PHP community today makes PHP look almost exactly like Java, with all of Java's drawbacks and none of its benefits.
Hey, I liked PHP too! But plopping strings from the HTTP request into the SQL query was icky. Is there something nice and modern I could use for stateless database-backed serverside apps with instant reload?
I simply must...https://toggl.com/programming-princess
D - it could be a replacement for many languages right now, and in many aspects is superior to Go, but since it lacks a big brand behind it, people are afraid to use it (although some do, successfully).
Another one is Nim, with great potential, but still some rough edges here and there.
Last but not least: Red. If this language gains momentum, it will change the game forever. The current implementation take the concept of cross-compilation to a new level (although the current lack of View on Linux is somehow disappointing.)
Another one is Nim, with great potential, but still some rough edges here and there.
Last but not least: Red. If this language gains momentum, it will change the game forever. The current implementation take the concept of cross-compilation to a new level (although the current lack of View on Linux is somehow disappointing.)
Clojure. It’s built on top of JVM, it’s dynamically typed but it makes so much sense, it’s probably language that makes most sense out of dynamic type system. It really is language for solving problems, if you get past that initial brackets lisp barrier, it is amazing, very efficient and it feels really good to solve problems with it. I don’t know why but it just feels great to use it. Plus it has really nice tools for Emacs. I am learning it and really enjoy it, astonishingly powerful.
Nobody loves Perl, but it holds the world together.
Perl is happily unoptimized for anything, and is usable for nearly everything. It's easy to write and easy to make it hard to read.
You can write Lisp in Perl, and some people insist on it.
The CPAN repository has a module for nearly everything, and an amazingly high percentage are well documented.
There are some weirdos who love Perl.
Perl is happily unoptimized for anything, and is usable for nearly everything. It's easy to write and easy to make it hard to read.
You can write Lisp in Perl, and some people insist on it.
The CPAN repository has a module for nearly everything, and an amazingly high percentage are well documented.
There are some weirdos who love Perl.
I don't like perl a lot exactly because it's easy to make it hard to read, but I gotta give that CPAN is the best language specific package manager I've ever encountered.
I strongly disagree that CPAN is the best package manager. The CPAN repository might be one of the largest for a specific language, but the cpan comnand line is aegul, you can't even remove a package automatically with it.
Don't get me wrong, because I love Perl, it was my main language for 10+ years, but the default package manger us awful.
cpanm
Perl is basically lisp for Pirates who got banished using Lisp in production environments.
No other language has done more to carry the Lisp legacy forward than Perl.
No other language has done more to carry the Lisp legacy forward than Perl.
I love perl. I also love Haskell and Python, but Perl was my first love.
The whole Wirth family of languages. They had clean, readable syntax, proper modularity, fast compilation, good performance, safety, productivity, GNU compilers. But they were shunned because people apparently didn't want to type "begin" and "end" and preferred unintelligible, clever tricks in C.
I'm excited to do some more Pascal in the near future. From what I know about it I can attest to some of your points (fast compilation and performance). However I do consider the syntax one of the main points why I stick with it. It is elegant and extremely efficient, if you know how to use it. It is indeed quite clunky to have to write so many begins and ends (after all, there is typically one of them each 3 lines or so).
And you shouldn't use unintelligible, clever tricks in C, at all. They are very easy to avoid (although I agree that even K&R had some of those in it).
Related:
http://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favo...
http://www.lysator.liu.se/c/bwk-on-pascal.html
And you shouldn't use unintelligible, clever tricks in C, at all. They are very easy to avoid (although I agree that even K&R had some of those in it).
Related:
http://wiki.lazarus.freepascal.org/Why_Pascal_is_Not_My_Favo...
http://www.lysator.liu.se/c/bwk-on-pascal.html
Not just syntax. All of Wirth's languages are extremely poor languages with no possibility to grow them.
He was stuck in the structural programming world and never ever got out of it. Besides, there's no single ultimate Wirth programming language. All of them are re-hashes of each other with random additions thrown in (Modula, Pascal, Oberon, Active Oberon, Modula 2, you name it).
They are small fast programming languages. And that's about it.
He was stuck in the structural programming world and never ever got out of it. Besides, there's no single ultimate Wirth programming language. All of them are re-hashes of each other with random additions thrown in (Modula, Pascal, Oberon, Active Oberon, Modula 2, you name it).
They are small fast programming languages. And that's about it.
> All of them are re-hashes of each other
Or more charitably viewed, successive refinements consisting of collections of proven ideas, with the ideas that didn't pan out in earlier iterations left out, yielding a body of languages that have had wide influence.
Or more charitably viewed, successive refinements consisting of collections of proven ideas, with the ideas that didn't pan out in earlier iterations left out, yielding a body of languages that have had wide influence.
To me it's Elixir. My company is a PHP shop, which results in complicated OOP stuffs (from most junior devs), as well as the inability to take advantage of concurrency. The syntax of PHP makes me sick just to look at.
PHP can be nice to look at. Laravel is a pretty good example of that: https://laravel.com/
Probably not underrated but not very well known. I’d say Julia as it easily one of the best script languages.
But I’ve also wondered why D is not more widely used as it is a much nicer version of C++ and integrates fairly well with it.
Also a bit odd that OCaml and SML isn’t more widely used
But I’ve also wondered why D is not more widely used as it is a much nicer version of C++ and integrates fairly well with it.
Also a bit odd that OCaml and SML isn’t more widely used
I wouldn't use Julia for scripts because of its overhead. I wrote a udp packet flinger for work to test packet throughput in about 10 lines server, 10 lines client (yay!) But when I wanted to deploy to Amazon, the images took about an hour to build.
Generally speaking applicatio startup time in Julia is poor (maybe because of the number of symbols in Base?), I only recommend using it for its original purpose - mathematical computation - which, by the way, it's insanely good at and an absolute joy to code in.
Generally speaking applicatio startup time in Julia is poor (maybe because of the number of symbols in Base?), I only recommend using it for its original purpose - mathematical computation - which, by the way, it's insanely good at and an absolute joy to code in.
This depends on your definition of "underrated" but I'd definitely throw Perl 5 into the ring here.
Edit: Specifically, Perl 5 + CPAN is what makes it so much better than many people think. The language itself is insanely flexible, which lends itself to extensions that greatly increase its expressiveness. IMO, if you start with Moose (from the CPAN) as part of your "core library" Perl 5 becomes a very powerful tool for writing very nice code, at any scale.
Edit: Specifically, Perl 5 + CPAN is what makes it so much better than many people think. The language itself is insanely flexible, which lends itself to extensions that greatly increase its expressiveness. IMO, if you start with Moose (from the CPAN) as part of your "core library" Perl 5 becomes a very powerful tool for writing very nice code, at any scale.
Lisp.
Its the most powerful language that has been in existence and yet most modern programmers haven't heard about it or used it.
Almost everything to do with the ecosystem is magic, and its not even a programming language by many a measure, its a thinking paradigm so powerful that it could make many things that look impossible a walk in the park. I've only been learning it for more than a month now, and this is what I've seen.
1. Unmatchable features when it comes to modifying structured data of any kind. Many eons ago our foregeeks seemed to have imagined everything in computer science as either a list or combination of lists on somekind. Tree, Queues, Heaps, Stacks, Vectors, Graphs, Sequences, Sets... You name it, these are all lists or a combination of lists. The programs too are lists(abstract syntax trees). Most modern day data structures you will will deal with XML, JSON, Tables, Matrices are lists or a combination of lists. And lisp is list processing. Once you get a hold of lisp and its paradigm of thought, even difficult algorithms and data structures feel like a walk in the park. I used to struggle with white board coding and algorithm stuff, these day most of it comes to me naturally or little work, when I think of it in terms of lisp paradigm.
2. Recursion: For some reason, its very easy to think recursively in lisp. And that makes very easy to represent hard solutions.
3. Functional programming: Full functional programming features, no holds barred.
4. REPL: If you haven't used the Lisp REPL, you haven't seen a real REPL yet. I was completely blown away by the REPL. Combination of Emacs + SLIME is just too good. And you can hot swap code by attaching to a live process. Which is totally insane.
4. Continuations: Makes it very easy to express a variety backtracking problems.
5. Macros: Ability to extend and add any language feature and paradigm you want, at compile time at 0 costs. And anything you add becomes a part of the language.
6. Libraries: Most lisps these days have libraries for most of the needs.
7. Books: Lisp easily has the most eccentric, fun and enlightening books in all of CS history.
When you code in lisp it feels you are dropping tiny little recursive functions all over the place which grow like a small organism to a very intelligent being.
This is closest I have to come to programming Nirvana so far. The last time before this was when I used Perl.
Its the most powerful language that has been in existence and yet most modern programmers haven't heard about it or used it.
Almost everything to do with the ecosystem is magic, and its not even a programming language by many a measure, its a thinking paradigm so powerful that it could make many things that look impossible a walk in the park. I've only been learning it for more than a month now, and this is what I've seen.
1. Unmatchable features when it comes to modifying structured data of any kind. Many eons ago our foregeeks seemed to have imagined everything in computer science as either a list or combination of lists on somekind. Tree, Queues, Heaps, Stacks, Vectors, Graphs, Sequences, Sets... You name it, these are all lists or a combination of lists. The programs too are lists(abstract syntax trees). Most modern day data structures you will will deal with XML, JSON, Tables, Matrices are lists or a combination of lists. And lisp is list processing. Once you get a hold of lisp and its paradigm of thought, even difficult algorithms and data structures feel like a walk in the park. I used to struggle with white board coding and algorithm stuff, these day most of it comes to me naturally or little work, when I think of it in terms of lisp paradigm.
2. Recursion: For some reason, its very easy to think recursively in lisp. And that makes very easy to represent hard solutions.
3. Functional programming: Full functional programming features, no holds barred.
4. REPL: If you haven't used the Lisp REPL, you haven't seen a real REPL yet. I was completely blown away by the REPL. Combination of Emacs + SLIME is just too good. And you can hot swap code by attaching to a live process. Which is totally insane.
4. Continuations: Makes it very easy to express a variety backtracking problems.
5. Macros: Ability to extend and add any language feature and paradigm you want, at compile time at 0 costs. And anything you add becomes a part of the language.
6. Libraries: Most lisps these days have libraries for most of the needs.
7. Books: Lisp easily has the most eccentric, fun and enlightening books in all of CS history.
When you code in lisp it feels you are dropping tiny little recursive functions all over the place which grow like a small organism to a very intelligent being.
This is closest I have to come to programming Nirvana so far. The last time before this was when I used Perl.
I strongly concur with this. I'd like to point a very specific thing out, which you only implicitly refer to:
It still makes me wonder though - here we are, the concept is 50 years old, and we're still bolting lexers together.
homoiconicity
It still makes me wonder though - here we are, the concept is 50 years old, and we're still bolting lexers together.
Homoiconicity just means that procedures are stored in the same representation in which they are entered, or nearly (modulo tokenization and such). It was defined that way by the programmer who coined the term in the 1960's, and is well documented in the Wikipedia.
POSIX shells are homoiconic; you can type set to see all the functions, which are printed in reformatted source code, that you can copy and paste.
That could work in any interpreted language. Classic line number BASIC is homoiconic. You can LIST the lines of code.
A Lisp is useful even if it isn't homoiconic (functions cannot be edited). ANSI Lisp has some loosely defined support for homoiconicity via the ed function. This isn't used much; actual Lisp environments have other means to recall and edit a function definition, such as an IDE with buffers or REPL with history.
The term homoiconic doesn't really "nail it" when it comes to Lisp.
POSIX shells are homoiconic; you can type set to see all the functions, which are printed in reformatted source code, that you can copy and paste.
That could work in any interpreted language. Classic line number BASIC is homoiconic. You can LIST the lines of code.
A Lisp is useful even if it isn't homoiconic (functions cannot be edited). ANSI Lisp has some loosely defined support for homoiconicity via the ed function. This isn't used much; actual Lisp environments have other means to recall and edit a function definition, such as an IDE with buffers or REPL with history.
The term homoiconic doesn't really "nail it" when it comes to Lisp.
I think Perl 6 has this concept of using the language to modify itself. Not exactly through homoiconicity, but the concept is somewhat similar.
sub infix:<d> ( $count, $faces ) {
(1..$faces).roll($count)
}
# from this point on the language has changed to have a
# new infix operator
say 5 d 20;
# (13 5 3 3 14)
NewtonScript was certainly underrated. Its use of frames with persistence (Soup) with queries was eye opening. I also loved the ease of UI development due to a proper prototype-based framework.
A further development of F-Script should have been the successor to Objective-C instead of Swift. It was fun and its APL influences really complemented the Objectice-C / Smalltalk collections. It also respected Objective-C conventions.
A further development of F-Script should have been the successor to Objective-C instead of Swift. It was fun and its APL influences really complemented the Objectice-C / Smalltalk collections. It also respected Objective-C conventions.
I really enjoy Ruby, Lua, and Lisp.
I find it interesting none of them are really used a ton in industry, but I've written my own Civ V and Civ VI mods (and helped other people with theirs). Lua is pretty much a pleasure to work with everytime.
Lisp is one of those odd balls, that is both prelevant, but also rarely seen in industry. My primary interaction has been with Scheme, Racket, and elisp. Wiring modes for Emacs is always fun (in elisp) and amazingly short, consise, and powerful.
Ruby is a dream, mostly I use it for Rails, but the whole ecosystem is well thought out and worth the time (what little you need) to put in. I've setup websites at scale in Ruby on Rails, with components written in Ruby inline C to make it much faster, an NLP library and much more (https://projectpiglet.com/). Better yet, I've seen non-programmers pick it up in a few weeks. Honestly, when I hear someone is developing an app in Springboot (Java) or some other webframework, I'll often show them they can complete their whole app in a couple days with Rails.
I find it interesting none of them are really used a ton in industry, but I've written my own Civ V and Civ VI mods (and helped other people with theirs). Lua is pretty much a pleasure to work with everytime.
Lisp is one of those odd balls, that is both prelevant, but also rarely seen in industry. My primary interaction has been with Scheme, Racket, and elisp. Wiring modes for Emacs is always fun (in elisp) and amazingly short, consise, and powerful.
Ruby is a dream, mostly I use it for Rails, but the whole ecosystem is well thought out and worth the time (what little you need) to put in. I've setup websites at scale in Ruby on Rails, with components written in Ruby inline C to make it much faster, an NLP library and much more (https://projectpiglet.com/). Better yet, I've seen non-programmers pick it up in a few weeks. Honestly, when I hear someone is developing an app in Springboot (Java) or some other webframework, I'll often show them they can complete their whole app in a couple days with Rails.
Prolog, Prolog, Prolog.
Genuinely curious - does the need for logic programming often arise in general software development? Or do I have a narrow view of what Prolog is good for? (I've worked a few toy problems with Prolog back in uni, but don't actually know the language very well.)
Logic programming is programming. It's like saying does the need for procedural or OOP or functional programming arise in software development.
It's a different style of programming, the mental state of the program when using prolog is to declare the rules that must hold true for the program to execute. You think less about state and more about logic.
In my opinion, here's what's amazing about this. There are programs that you might have a hard time solving via other means that you can easily solve with Prolog if you know the rule.
If you know the rules all you need to do is state the rules, and Prolog will find the solution for you. Besides being great for quick prototyping and application of rules. You can build complete systems with it. SwiProlog has HTTP, SSL, ODBC and even GUI support.
It's a different style of programming, the mental state of the program when using prolog is to declare the rules that must hold true for the program to execute. You think less about state and more about logic.
In my opinion, here's what's amazing about this. There are programs that you might have a hard time solving via other means that you can easily solve with Prolog if you know the rule.
If you know the rules all you need to do is state the rules, and Prolog will find the solution for you. Besides being great for quick prototyping and application of rules. You can build complete systems with it. SwiProlog has HTTP, SSL, ODBC and even GUI support.
I'm pretty sure I'm the only person in the world who can say this, but I've been working with SWI-Prolog as my home automation controller for around 15 years. Last year I rewrote the system to make use of a library to allow SWI to publish/subscribe MQTT messages for communication between the components.
Logic programming just sounded like it would make sense for describing the behavior of a home automation system, and I think it works well.
Logic programming just sounded like it would make sense for describing the behavior of a home automation system, and I think it works well.
Any chance you have anything publicly available on this? That sounds like an awesome application of Prolog.
Forth. It's a procedural language stripped down to the absolute minimum amount of syntax. Somewhat like what lisp is to functional languages. Its low level and minimal overhead make it excellent for highly constrained embedded systems.
And absolute joy to implement! If anyone is curious: pick up "Threaded interpretive language" by R. G. Loeliger. It is old and only describes one kind of kinda-Forth -- but in a few readable lines of assembly and some neat memory structures you have an interpreted language.
I did some classes on the parallel language Occam-Pi back in uni. I really liked some of the designs - it's designed like a circuit diagram, with data flowing between segments in channels, and if no data is flowing, the channel and its attached segment blocks without consuming resources. It's also very easy to switch between series and parallel execution, and by designing it like an electrical circuit, it becomes possible to identify potential deadlocks and prove your program will function as expected. It's mostly an academic language, but it's worth looking at.
I would have said erlang as well, or possibly smalltalk, but I guess it depends on how you define underrated.
Smalltalk is definitely underrated. It can be an extremely productive language, and has built-in capabilities you won't find in any "mainstream" language that make coding in it very pleasant. :)
http://claylabs.com/clay/
Clay is a language that is no longer being developed, but it was a well designed substitute for C. It was built with templates in mind from the ground up and has modules, move semantics and no garbage collection.
Also Intel's ISPC. If you want real speed, ISPC makes it much more practical to take advantage of SIMD, though it seems not many people know about it.
Clay is a language that is no longer being developed, but it was a well designed substitute for C. It was built with templates in mind from the ground up and has modules, move semantics and no garbage collection.
Also Intel's ISPC. If you want real speed, ISPC makes it much more practical to take advantage of SIMD, though it seems not many people know about it.
English.
You can write your requirements in this language, then send to a programmer to convert them to code.
You can write your requirements in this language, then send to a programmer to convert them to code.
I think Racket is underrated. (Dunno about "most underrated".)
It's a batteries-included Scheme/Lisp dialect with the best documentation I've ever seen, a state-of-the-art macro system, and a very friendly community. It has performance better than your typical dynamic language (Python, Ruby) though not as good as the highly optimized ones (Javascript V8, LuaJIT).
It's a batteries-included Scheme/Lisp dialect with the best documentation I've ever seen, a state-of-the-art macro system, and a very friendly community. It has performance better than your typical dynamic language (Python, Ruby) though not as good as the highly optimized ones (Javascript V8, LuaJIT).
Just to add to your comment, DrRacket is a very wonderful IDE.
C.
Often people don’t learn anything about a language’s internals, or a computer’s internals, when they learn a “nice” language with garbage collection and dynamic typing and massages. IMO for long-term software engineering that stuff is important to know.
Many see C as this old, outdated, uncool language, and never even realise that so many other languages are written in it.
But really, when it comes to perf and correctness, it’s still king:
- Often you can try to optimize a simple python program to make it run faster... or you can rewrite it in C and get a 1000x boost for free
- It has compilers that have proofs of correctness
- There are many tools that can prove a C program’s correctness
- It’s still the best way (IMO) to learn how the computer works while learning the language
- It doesn’t have OOP (which makes me sad), but you can get there by writing C++ as “C with classes”
- It probably has the most job security guarantees of any language: it will be a looooong time before C goes away
- It’s so standard and supported, programs from 40 years ago still run today; I don’t know if you can say that about any other language (except like, COBOL)
Often people don’t learn anything about a language’s internals, or a computer’s internals, when they learn a “nice” language with garbage collection and dynamic typing and massages. IMO for long-term software engineering that stuff is important to know.
Many see C as this old, outdated, uncool language, and never even realise that so many other languages are written in it.
But really, when it comes to perf and correctness, it’s still king:
- Often you can try to optimize a simple python program to make it run faster... or you can rewrite it in C and get a 1000x boost for free
- It has compilers that have proofs of correctness
- There are many tools that can prove a C program’s correctness
- It’s still the best way (IMO) to learn how the computer works while learning the language
- It doesn’t have OOP (which makes me sad), but you can get there by writing C++ as “C with classes”
- It probably has the most job security guarantees of any language: it will be a looooong time before C goes away
- It’s so standard and supported, programs from 40 years ago still run today; I don’t know if you can say that about any other language (except like, COBOL)
I'm presently working my way through Kernighan and Ritchie, and the more I dig in, the more I enjoy it.
I love the large feature sets with some other languages for certain projects, but the small size of C makes it easy to wrap one's head around the basics. The extended learning comes from problem solving due to specific limitations.
My biggest beef is probably a little to do with number sizes (64b ++), but I just haven't learned the best method for dealing with them.
I'd dabbled in it before, but this book really does open it up wide.
And the potential for working with embedded devices in a more profound way, it can't really be beat, no?
I love the large feature sets with some other languages for certain projects, but the small size of C makes it easy to wrap one's head around the basics. The extended learning comes from problem solving due to specific limitations.
My biggest beef is probably a little to do with number sizes (64b ++), but I just haven't learned the best method for dealing with them.
I'd dabbled in it before, but this book really does open it up wide.
And the potential for working with embedded devices in a more profound way, it can't really be beat, no?
I get much of the effortless correctness (at least the "seems to work" type of correctness) by not trying to do OOP. Frankly that's a mess, especially when trying to emulate it in C.
Instead I use simple data table driven control flow, global state, etc.
Instead I use simple data table driven control flow, global state, etc.
FreePascal/Lazarus.
PostScript - just because I had some mind bending fun with it years ago in NeWS & HyperNeWS
Have a look at Parallel U niverse's Quasar. It's q Java library that provides lightweight threads called fibers. They have some interesting older entries in their blog with benchmarka and comparisons to Akka etc
Icon was a language I used in my youth. It took me a long time to unlearn some of the very neat features of the language.
if 1 <= x < 99 rather than if 1 <= x && x < 99 and a host of much more natural expressions
if 1 <= x < 99 rather than if 1 <= x && x < 99 and a host of much more natural expressions
This is one of the things I like in Python
The Q Language: http://code.kx.com/q4m3/0_Overview/#00-the-evolution-of-q
I would say Erlang and OCaml are compared to Go despite being in a similar space and having particular advantages. It seems like Go gained traction over them largely due to Google's backing and having a Python-like philosophy of aesthetics - namely simplicity and readability over sophisticated features - and it seems like many Go developers came mostly from Python.
You can take my perception with a giant grain of salt though: I mostly write Scala these days, which has to be Go's polar opposite of popular languages in terms of design philosophy.
You can take my perception with a giant grain of salt though: I mostly write Scala these days, which has to be Go's polar opposite of popular languages in terms of design philosophy.
Tcl
Fortran. 60+ years and still useful code used widely thanks to netlib and certain BLAS implementations.
Has many superb (proprietary) compilers and handles math like it is nobody business without having to drop into manual vectorization tricks like C and C++.
Given good variable naming convention it is quite readable too. It is still being developed and enhanced as a language.
Has many superb (proprietary) compilers and handles math like it is nobody business without having to drop into manual vectorization tricks like C and C++.
Given good variable naming convention it is quite readable too. It is still being developed and enhanced as a language.
But only quite. As a physicist I had to deal with FORTRAN and moving to C was such a relief (just this sentence shows the amount of pain).
The next generation with their pandas is spoiled.
The next generation with their pandas is spoiled.
I think it's Crystal lang, it have a very nice syntax and performance compared to go / rust / c++
I liked lua when I used it. It didn't seem to get much love at the time, though I think it's more popular. It's got a few neat things and it's good for embedding. And I think maybe D doesn't get the appreciation it deserves but there's a bunch of reasons for that.
I kind of wish D would pick up. It's very familiar and clean, and a few things are remarkably easy and fun to do.
Though reading through issues and threads about it, and maybe high performance programmers using it have more than a few things to say about the state of the GC. I'm not sure if that's changed or not. I've only dabbled yet.
I'd like to see a community grow around it. It, or something like it, seems to me like the path a modern, low-level language should be going. It's not there yet, but in terms of the feature-set, optional safety, syntax, typing, etc, it's an attractive space.
Though reading through issues and threads about it, and maybe high performance programmers using it have more than a few things to say about the state of the GC. I'm not sure if that's changed or not. I've only dabbled yet.
I'd like to see a community grow around it. It, or something like it, seems to me like the path a modern, low-level language should be going. It's not there yet, but in terms of the feature-set, optional safety, syntax, typing, etc, it's an attractive space.
The luaJIT compiler[0] is stupendously good. Bob Nystrom, one of the developers for Dart, once said "Mike Pall [the developer] is a robot from the future"[1].
[0] http://luajit.org/luajit.html
[1] http://wren.io/performance.html
[0] http://luajit.org/luajit.html
[1] http://wren.io/performance.html
+1 to Lua, it is my favorite interpreted language. I like that the design is extremely clean and consistent, not to mention it is way faster than the alternatives.
Did anyone mention parasail? It's a statically typed programming language with region based memory management, builtin parallelism of every expression, and a number of other quite entertaining design decisions. I think it's a shame nobody has heard about it.
Smalltalk
Programming language != runtime. Erlang-the-language is pretty flaky, but the VM where it runs (plus OTP) is pretty insane.
Same for Java, the language itself is pretty boring, but the runtime (JVM) is great.
C# is the opposite, the language is great but the tooling and runtime are not there yet.
Same for Java, the language itself is pretty boring, but the runtime (JVM) is great.
C# is the opposite, the language is great but the tooling and runtime are not there yet.
I would say Ceylon. Ok I never used it, but it looks like it has one of the cleanest type systems ever, and flow-based typing is a really clever idea that isn't really in any other languages.
Sad that it has been abandoned by Red Hat.
Sad that it has been abandoned by Red Hat.
Excel.
Delphi
I'm going to say Groovy.
It allows you to do all the nifty things Java does, but you just feel infinitely more productive.
Apache Groovy brought closures to the JVM in its day, something no other JVM language had at the time, kudos to its creator James Strachan who was dissatisfied with Beanshell. Now that Java 8, Kotlin, Scala, and Clojure also brought closures/lambdas mainstream, I'm not really sure what unique proposition Groovy brings to the JVM any more.
Grails is an amazing powerful web framework. Favorite feature of it is GORM. Quite expressive
javascript too pop to be noticed.
I'd argue it's more misunderstood than underrated.
Given (historical) alternatives of flash and java:
Want some simple scripting on a web page? JavaScript, hands down
Want a full page takeover as an app? Java didn't make much sense here- the startup time was awful, and you might as well have literally just made a java desktop app. Flash too had limitations- you could (and I have) throw something together pretty quickly with flex, but the loss of the mobile market was unfortunate.
With that said, you are afforded many paradigms, from fully OO to fully functional (from GWT, to Angular, to React, to Purescript), with everything from static, compile time safety (typescript and flow) to runtime clojure-spec ish typing supporting ADTs (tcomb, io-ts, folktale, fantasyland).
There's canvas and webgl, but with the DOM having accessibility primitives built-in, you really don't need or want to go there unless you absolutely have to.
For every fault of the language, a third party came to the rescue- from module systems (require/amd => browserify/cjs => system/webpack/tsc/ => native modules) to macros (sweet.js) to DSLs (peg.js) to whatever you can think of, all on NPM (for better or worse).
There's a lot to hate about JS. There's a lot to love, if you give it a chance without carrying emotional baggage.
A lot of these things have absolutely ruined the modern web- I hate the popups on every news website wanting to send me push notifications, and every other blog pretending to be a SPA.
A lot of these things have made business advancements possible- I once took a downloadable part configurator app from a company, which could only be installed on windows, and converted it into a web site. Average quote turnaround went from 2-3 weeks to a salesperson could walk into a customer's office, walk them through the website on an iPad, and have a quote in 15 minutes.
JavaScript, and the web platform in general, have been maligned, misunderstood, inappropriately used, but it has also been a fundamental changing point in our usage of computers, in many cases for the better.
Given (historical) alternatives of flash and java:
Want some simple scripting on a web page? JavaScript, hands down
Want a full page takeover as an app? Java didn't make much sense here- the startup time was awful, and you might as well have literally just made a java desktop app. Flash too had limitations- you could (and I have) throw something together pretty quickly with flex, but the loss of the mobile market was unfortunate.
With that said, you are afforded many paradigms, from fully OO to fully functional (from GWT, to Angular, to React, to Purescript), with everything from static, compile time safety (typescript and flow) to runtime clojure-spec ish typing supporting ADTs (tcomb, io-ts, folktale, fantasyland).
There's canvas and webgl, but with the DOM having accessibility primitives built-in, you really don't need or want to go there unless you absolutely have to.
For every fault of the language, a third party came to the rescue- from module systems (require/amd => browserify/cjs => system/webpack/tsc/ => native modules) to macros (sweet.js) to DSLs (peg.js) to whatever you can think of, all on NPM (for better or worse).
There's a lot to hate about JS. There's a lot to love, if you give it a chance without carrying emotional baggage.
A lot of these things have absolutely ruined the modern web- I hate the popups on every news website wanting to send me push notifications, and every other blog pretending to be a SPA.
A lot of these things have made business advancements possible- I once took a downloadable part configurator app from a company, which could only be installed on windows, and converted it into a web site. Average quote turnaround went from 2-3 weeks to a salesperson could walk into a customer's office, walk them through the website on an iPad, and have a quote in 15 minutes.
JavaScript, and the web platform in general, have been maligned, misunderstood, inappropriately used, but it has also been a fundamental changing point in our usage of computers, in many cases for the better.
If by this you mean that it’s not taken as seriously because it’s pop, I agree. I’ve been seeing more and more node.js in the enterprise stack and in IoT for smartcity projects.
Modula-3
Lisp, and dialects like Scheme, Emacs Lisp, and Clojure.
[1]blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/ [2]https://stackoverflow.com/q/2708033/2577465