(I wasn't sure this fitted in 'Coding', if i must i'll move it)Talk about your favorite programming language(s)!Talk about the do's and dont's, the tips and tricks Let me start.... RustRust is practically amazing, in my opinion, for both its portability (as long as LLVM can work for that platform) and its flexibility.I like its memory safety oriented design and its immense flexibility for extending the compiler (Nightly only) and the fact it can work in most environments (See redox os, which has its kernel written in almost pure rust). It even has a online sandbox if you want to try it, so may as well link a few resources:https://doc.rust-lang.org/https://play.rust-lang.org/https://www.rust-lang.org/

The right board is called Religious Wars. Because taste can be argued and my favourite language is my favourite simply because it's the best.

Haskell (and friends, though I'm only familiar with Haskell) makes me feel funny because of its extensive pattern matching and lazy evaluation ...and types ...and composition ...and basically everything that is modern functional programming. I just love combining functions to create a complex data transformation without having to use variables. Most languages include a map and sometimes a reduce and filter nowadays, but I can't just put length . cyclesOfSize 4 in that map. Instead, it would require a whole inline function graph => length(cyclesOfSize(4, graph)) —where's my point-free utopia?

But other than making me swoon over type theory and being smart at evaluating simple programs, I like it just as much as a lot of other languages. I have yet to give TypeScript and Rust a go.

For ease of use in proving a concept: Perl (controversial, I know, if only for it being more a scripting language)

For stability/universality: I generally fall back on one or other generation of core C, depending upon the minutiae of the hardware interface/abstraction methods needed and allowed.

If I just want to create a Windows application with click buttons and things but no actual finesse: I'll dig up my Delphi disks (or perhaps go get Lazarus, if it plays better on newer platforms).

I've yet to settle on a 'modern' platform for contemporary (and potentially cross-platform) App development, still mostly jumping between the C family members, according to what various DevKits seem to best support, but there are so many options available...

And then there's the language of my own development (for a quarter of a century, now... wow, time flies!), an esoteric ultra-RISC (four instructions1) code base that'd probably run economically on an FPGA assembly, but mostly I'm messing about in other languages to create virtial platforms, rather than using it as a language itself... It's probably just what I turn to when I need reassurance that I'm better at something than anybody else, based on the fact that nobody else even knows about it.

1 None of this "any or all operands can be literal, absolute reference, relative reference, indirect reference via another (absolute/relative/register) reference, etc, in any combination, but it's still the same instruction!" thing...

Tub wrote:So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

What was Java's "shining" example?

That was JavaServer Pages, right?

I guess it shines at being semi-cross-platform and embeddable in browsers in the 90s. And it has millions of code snippets and libraries and tutorials and examples, so, if you need to quickly hack something together, it may as well be the best suited language for your problem.

Tub wrote:So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

What was Java's "shining" example?

*runs*

C#.

I prefer Haskell tho. Hell, when I need a quick calculation(read: wait, what was sin (exp 3.12) again? Ah, right -0.61...), I just open up a shell and type "ghci" and do my calculations, why bother with some builtin calculator application? Well, I sometimes just type simple expressions into google if I have the browser open.

Sure, java got a lot of things wrong that c# eventually got right, but writing code for the JVM opens up a whole ecosystem of useful tools for deploying, managing, juggling and even cloudifying the resulting software. That's unlikely to be useful for private projects, homework or finishing project euler, but remember that most of the world's software development is done internally by corporations in order to solve a business problem. And for some of those problems, java is the best choice.

Tub wrote:So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

What was Java's "shining" example?

*runs*

The standard library is god tier. No other language even compares to it. If I need to write something that I know is going to need to depend on a lot of stuff that I don't want to implement myself, I'll probably use Java just for the library.

I actually don't find Java significantly more verbose than any other language. Especially now that it has lambdas. In fact, I find Java universally less verbose than C++. The lack of good list comprehensions is the only thing that's really missing from it now. Most of the verbosity and boilerplate that I see in practice comes from the style of coding, not the language. In particular dependency injection creates a lot of boilerplate code and encourages the use of providers and factories that increase verbosity. However dependency injection is not in any way tied to Java. You can write Java without it, and you can use it in any language. Furthermore, there are good reasons to use dependency injection, the most significant of which is that it makes unit testing much easier. But if you don't want to use it, you don't have to. Don't use DI in your code, use lambdas liberally, and skip out on some other boilerplate (like using public members instead of getters) and Java isn't verbose at all.

I'm not saying it's a perfect language or anything, there are a lot of flaws I could mention, but those are all shared by many other languages as well. But the main criticism I see is that it's verbose, and I don't agree with that.

Tub wrote:Languages are tools, not pets. Use the right tool for the right job. As awesome as rust's safety guarantees are, sometimes a bash one-liner is all you need.

So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

True, so we should probably mention the problem case here. Still, some languages are move lovable regardless of the use case.

My first "amazing language" was Visual Basic. While I first learned to code in 8-bit BASIC (and all the damage that implies) [and had written much more x86 assembler, probably more assembler than Visual Basic no matter how much VB I wrote], this allowed an easy way to learn the language (and between QuickBasic and Visual Basic [2.0] they had fixed nearly all of BASICS major disasters). But if the "language" wasn't all that lovable, the slick integration with the GUI [and designer] certainly was. It made the hard parts (UI design) trivial and thus made the whole design 90% easier.

The fatal flaw was trying to integrate your own libraries. Eventually I had a project that needed libraries that didn't exist for for VB (then probably 5 or 6) and trying to compile C code into a DLL that VB could use was an enormous task, enough to offset any gains in building the UI (which wasn't the big issue for this project).

Enter Python. Python has nearly the reverse issue. The base syntax/language is extremely lovable (some claim that this leads to obsessed fanboyism and hate to be associated with such things), libraries could be easily assembled (at least with SWIG and 2.x, not sure the current method), but it doesn't have an official GUI library (other than Tcl/TK) and you are essentially on your own (a number of libraries exist, but have to be forced into python code).

How about "programming FPGAs via schematic capture? It certainly seems more natural than Verilog, but certainly slower to implement. I'd certainly have an easier time checking/debugging the schematic than the code and this might win in the end.

Ah. 32-bit x86 isn't bad, although I do prefer more orthogonal architectures. It's probably the last major architecture that was designed from an assembler programmer's standpoint, so you don't have issues like with a lot of the RISC architectures where, say, it takes multiple steps just to load a full-word constant.

(Hell, even 16-bit x86 isn't as bad as it's made out to be - segmented addressing is weird and a bit annoying, but it's far more of an issue for compiled languages, where handling it in a generic case requires things like separate types for near and far pointers or such.)

"'Legacy code' often differs from its suggested alternative by actually working and scaling." - Bjarne Stroustrupwww.commodorejohn.com - in case you were wondering, which you probably weren't.

Tub wrote:So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

What was Java's "shining" example?

*runs*

The standard library is god tier. No other language even compares to it.

Absolutely agree with you on this one. I think a lot of the flak Java gets (verbosity, performance, etc.) is based on really out-of-date information—like, from the 90's. For the most part, Java is surprisingly good for the amount of hate it gets.

There are really only two things that I really dislike about java: Boilerplate and Type Erasure.

The amount of boilerplate code required to implement common patterns (this is a different type of verbosity from what most people complain about, I think). For example, making a POJO that properly implements equality and hashing requires a lot of boilerplate, and while IDEs can generate this code for you, it's hard to see at a glance whether or not the boilerplate has been modified from the default, which makes it hard to debug and reason about.

As for Type Erasure, I know why they did it, and there are plenty of ways to work around it, but for every major project I work on, there are invariably a few unavoidable unsafe casts that work their way in there, and that bugs me on principle.

Fortunately, Kotlin does a lot to mitigate these issues, while keeping the strengths of Java (the JVM, the awesome standard library, to name a few). I love that I can use Kotlin with existing projects and it interoperates seamlessly, and I love that it eliminates a lot of boilerplate (especially for defining POJO classes). I have a few minor gripes with it (as with any language) but I have found in practice that I am able to produce working production-quality code much, much more quickly (3x to 4x more quickly) working in Kotlin. Partly because the language is awesome and it has the Java library available, but also because the language integration with the IDE (I use IntelliJ IDEA) is among the best I've ever seen.

I rarely have "favorite" when it comes to programming languages (as has been said, it's largely a matter of taste), but in a very concrete sense, the switch to Kotlin has vastly improved my team's productivity and vastly reduced crashes in production code (and development code—I think in the last 4 months, we've seen only a single NPE even in development! The compiler catches SO MUCH more than the Java compiler...)

Tub wrote:So far, every language I met had *some* use case where it shines, and *some* use case where it's a poor choice.

What was Java's "shining" example?

*runs*

The standard library is god tier. No other language even compares to it.

Absolutely agree with you on this one. I think a lot of the flak Java gets (verbosity, performance, etc.) is based on really out-of-date information—like, from the 90's. For the most part, Java is surprisingly good for the amount of hate it gets.

There are really only two things that I really dislike about java: Boilerplate and Type Erasure.

I mean the amount of boilerplate code required to implement common patterns (this is a different type of verbosity from what most people complain about, I think). For example, making a POJO that properly implements equality and hashing requires a lot of boilerplate, and while IDEs can generate this code for you, it's hard to see at a glance whether or not the boilerplate has been modified from the default, which makes it hard to debug and reason about.

As for Type Erasure, I know why they did it, and there are plenty of ways to work around it, but for every major project I work on, there are invariably a few unavoidable unsafe casts that work their way in there, and that bugs me on principle.

Fortunately, Kotlin does a lot to mitigate these issues, while keeping the strengths of Java (the JVM, the awesome standard library, to name a few). I love that I can use Kotlin with existing projects and it interoperates seamlessly, and I love that it eliminates a lot of boilerplate (especially for defining POJO classes). I have a few minor gripes with it (as with any language) but I have found in practice that I am able to produce working production-quality code much, much more quickly (3x to 4x more quickly) working in Kotlin. Partly because the language is awesome and it has the Java library available, but also because the language integration with the IDE (I use IntelliJ IDEA) is among the best I've ever seen.

I rarely have "favorite" when it comes to programming languages (as has been said, it's largely a matter of taste), but in a very concrete sense, the switch to Kotlin has vastly improved my team's productivity and vastly reduced crashes in production code (and development code—I think in the last 4 months, we've seen only a single NPE even in development! The compiler catches SO MUCH more than the Java compiler...)

There are naive mappings-to-assembly you can understand, sufficient abstraction that the compiler can do *better* than naive mappings to assembly.

You can (with modern C++) write code that is safe-by-default; I've seen what happens in huge code bases as we migrate it from paleo-C++ into modern C++. Entire categories of errors stop happening (except where you interact with paleo-C++).

The stuff coming down the pipe is just ridiculously fun. Reflection, but compile-time, which lets developers write run-time reflection only when we need it. Type functions and/or metaclasses, giving us compile-time reificaction in a near-metal language. Why be stuck with the object model of your langauge when you can write your own? Sure, lots of the "new" stuff (like the monadic stuff) is stolen from other languages.

It now has a first-class memory model that hardware manufacturers are using to formalize and change how their hardware works (NVidia used the C++11 memory model as the starting point for their memory model in next-gen compute GPUs, and then they've published back changes to the C++ memory model to reflect the real-world difficulties in massively-SIMD hardware use cases so C++ can map naturally to the hardware limitations). Esoteric stuff, but exciting.

I still enjoy Python, Haskell, etc. But I find myself thinking "how can I steal this and use it in C++". And often I can; something that behaves the same, but instead of having multiple levels of runtime abstraction between the code that the metal, there are a few compile-time layers that can evaporate at runtime.

One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision - BR

I used to code in Advance Java during my venture in Wipro. Currently I think there are new concepts and languages like fll stack, mongo db, python and c# which are being used for developing complex projects.

slintyflinty wrote:I used to code in Advance Java during my venture in Wipro. Currently I think there are new concepts and languages like fll stack, mongo db, python and c# which are being used for developing complex projects.