F-0X

> this sounds like every "low level developer" ever, in that the opinions are completely removed from reality. it isn't 19<whatever>.

Who cares what year it is. Fact is, with low level languages, you can write software which consumes less resources. This won't ever change.

> if by inefficient, you mean slow, then java isn't anywhere near comparable to javascript or python.

Sure, I (and presumably the poster you responded to) agree. Java is plenty fast for most things. But its memory usage is horrendous. Like seriously bad. It seems Intellij takes a solid 1.5gb to simply exist. I'd like to use Java (well, JVM based languages really) more, but basically all JVMs are memory hogs that take too long to start up. Graal might help here, we shall see.

C#, F#, Chez, et al. follow a similar suit. (Chez is probably the best of that lot, though. Would be my choice).

>I can't help but think of the 'Unix haters handbook' and groan

The one true gripe they outlined is that the user interface requires some explanation before one can bootstrap their own knowledge.

I'll defend the unix philosophy till I die, probably. Why _wouldn't_ you apply it here?

Even so, you can write code imperatively in scheme, it's just a bit less natural. The keyword 'begin' has the same semantics as common lisp's 'progn', which allows imperative code to be written.

I was careful to say "functional-first". Racket has a fully-fledged object system, too.

>I just wish it wasn't implemented in Scheme (only because I am not familiar with the language

It is a functional-first, small and clean variety of lisp. A much more beefed-up cousin is Racket, but some implementations of scheme (in particular Guile and CHICKEN) have excellent ecosystems.

Scheme is a language that deserves to be used more. It simplicity is deceptive. It is extremely powerful because although the basic components are simple, there is virtually no limitation on how they may be composed.

There is literally only a single drawback to using Scheme (it might appear that being dynamically typed is a weakness, but both CHICKEN and Racket offer typed variants), is that it is sadly extremely unportable. The specification for Scheme is very small, and a large number of implementations exist which go beyond this standard - so basically none are compatible with eachother.

> Machine learning techniques are AI, as the term has been used in industry and academia for decades.

As the poster said, most of them are just statistics; the term has been used in industry and academia for _centuries_.

Predictive models based on accumulated data is just what statistics is applied to do. Calling it AI academically is a big stretch, calling it AI in industry is a marketing technique.

Exactly. I would prefer they directed their budget somewhere other than graphics for this reason. The switch still plays most games at only 720p I believe, but this is more than sufficient for enjoyable games. I think 4k is a waste of memory, let alone 8k.

> And this is a dismissal of the idea that words have effects on people.

No. Context is important. A manager, a human being with authority, is very different to a standard, unchanging message baked into a program. Your claim and comparison (to me right now, correct me if I'm wrong) seems to be that IDE error messages are just as effective on the programmers feelings as the manager coming up to look at your code and pointing a finger while bluntly saying "this is incorrect". I don't believe this at all.

> Are all software tools the same experience for you - you never find one frustrating and another pleasant, one neutral and another you curse at?

They are not. Ironically it is the ones that don't produce direct error messages (especially css) that anger me the most.

> Nothing is wrong. That's the point. Unfinished code doesn't work, that's normal, not erroneous. (Almost tautologically so - of course it doesn't work, it's unfinished).

There's more than one state code can be in while incomplete. It can be incomplete because it doesn't accomplish the task it is being written for yet, but all the same it will still compile. If it is syntactically incorrect, it doesn't even matter if the logic attempted to be expressed is correct, the program is broken. But these errors are easy for a computer to expose - so they should, so problems are fixed as early as possible.

This seems to have a weird personification of a compiler/linter's error messages as a telling off, an insult, or a put-down.

It's just a message to highlight what is wrong. Red doesn't equate to bad, red equates to "this is a compilation blocker", just as yellow is typically used for "this will work but it isn't a good idea". The compiler _already is_ guiding the user to success.

If somebody is taking compiler errors personally, they are going to struggle in a lot more areas in life than writing code, and the issue is their frame of mind.

Can I really be the only one who clicked the link and _enjoyed_ the plainness?

I need to get this gripe off my chest. I want types on the left, and not optional.

I read the main function first. I saw that call to countOccurances, without an argument. I was confused how it was going to count occurances if it didn't know what it was looking for. Then I noticed the implementation of this method above.

Had there have been a type of Map<string, int>, I'd have reasoned what it does easily.

I hate type inference, it does not help.

Several?

Besides UI programming and not requiring users to install anything, what other advantages are there?

It's not a "forest of parens" any more than any language with C style syntax is, they're just in different places (the correct places) and there's no need to distinguish with braces (which you shouldn't need to).

I cannot understand this "solution" of turning to machine-verified proofs. Coq, Isabelle, etc. invariably contain bugs. Even if they didn't, you can still run into hardware bugs. Computers are not a source of perfect computation and software is certainly not a source of perfect logic.

As far as Common Lisp goes, you could just install the Portacle distribution of emacs. This is essentially a fully-geared up CL IDE, including all the favourite emacs extensions for development (flycheck, company, paredit, magit, etc) and even SBCL and git!

It provides a single user.el file for user-specific configuration, but as it stands it is an excellent "emacs with great defaults".

This is how I feel generally when working with codebases which make copious usage of type inference.

I hate it, and think it is simply counter-productive in most cases. Though most other developers scoff and this and can't understand why I'm happy to write "unnecessary types".

I long for a language where types are mandatory and on the left. But not Java <10.

>even the most jaded systems programmer can see are not ideal, like the fact that types precede names in variable declarations,

Honestly, I find it shocking anybody can hold this opinion.

I hate that every single new language insists on types being on the right. I searched for a reason why this is, and typically the results are along the lines of type inference being easier to implement. I'd prefer to take no inference at all and have my types on the left, where they belong. I'm totally serious.

Types on the right are a readability disaster.

I don't find his arguments convincing at all. The appearance of supporting privacy is not mutually exclusive with invasive behaviour internally, and records - even if supposedly kept private - is still potentially vulnerable to being hacked/leaked. The problem is they collect data to sell as this is literally their business, while true privacy is only achieved when personal data is not collected.

Absolutely, I think this would be a huge improvement. The ability to easily extract plaintext data locally would be a huge help with my personal organisation and planning.

>Static typing fans hardly ever acknowledge how difficult the types make it to read the code

I think types make code much more understandable. I like them to be explicit so there's no mental overhead of thinking "what type might this be" - and the larger the codebase, the more this pays off.