61–70 of 193 posts
Earlier quoted context omitted.
end, curly braces, same same. The deviation is IMHO Python with its intention oriented block creation. Which is a debate on its own ;).
I love the indents now with modern editors being able to deal with them ;) Zen mode. Super clean. No end delimiters.
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…
Java certainly doesn't: https://godbolt.org/z/b847KeaGv
There's a good reason for this. Computer numbers are not the same as numbers in mathematics. Floating point numbers are not real numbers and ints are not natural numbers.
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…
If I had a junior programmer complain to me about this case, I'd simply tell them "you didn't RTFM", because RTFM'ing before you use a language is not only the professional thing to do, but vital to your accurate and correct use of the language.
Sure, language designers shouldn't build-in these kinds of foot-bullets, but then again, kids shouldn't play with guns.
>First impressions apply to languages too.
The duty of responsibility applies to all languages, and it is the users responsibility to understand the language they are attempting to use, before using it. No?
Ruby always seems so appealing. Can anybody tell me how the Ruby ecosystem looks like w.r.t. - (Desktop) GUI - Natural language processing I would really like to learn Ruby, but I can only justify the effort if I can use its ecosystems for some private projects, and I often have been burned by languages not offering too much in those two areas. And speed-wise, as I understand, Ruby is the same ball-park as Python?
Ruby is only relevant because of Rails, and if those two things are your use-cases then you’ll be better off with Python
For NLP you will have less choice than for Python, but worst case you can bridge to Python code.
Ruby always seems so appealing. Can anybody tell me how the Ruby ecosystem looks like w.r.t. - (Desktop) GUI - Natural language processing I would really like to learn Ruby, but I can only justify the effort if I can use its ecosystems for some private projects, and I often have been burned by languages not offering too much in those two areas. And speed-wise, as I understand, Ruby is the same ball-park as Python?
15 years ago I made the choice between Python and Ruby. Without a doubt, choosing python was the correct move. I can't imagine with the current trajectory, Ruby will be better.
Hmm I'm no Python fan but I'd take it over Ruby any day, because it's so much easier to read a codebase. This is based on me trying to follow Gitlab's code. The problems with Ruby seem to be: * No static typing (I think there is Sorbet but apparently it's not very good and Gitlab doesn't use it). * The lack of "syntax" makes it hard to grep for things. For example you can't find where `foo` is called by searching for…
I wouldn't say it encourages it explicitly but it makes it far too easy. There is usually no need for highly dynamic code in code that is not part of a library.
> Ruby keeps going with its methods-first approach, except instead of each we have a new set of methods commonly implemented on collections, as below Once you implement `each`, `include Enumerable` is all it takes to get the full set of collection methods (including `max`/`min` etc, if the entries define ` `).
Indeed. The entire article largely read like "Python developer learns Ruby", and on top of that now fairly dated Ruby, though I'll make some concessions for him wanting to show a close parallel to the Python. I wish he'd signposted more clearly that these are examples, though, because as it stands it implies this is how to do things, while it really is not. E.g. his "Stuff" example can be reduced to: class Stuff def…
The Python example is similarly unidiomatic, reduceable, and flawed for the sake of simplicity (the example doesn't allow multiple independent Stuff iterators), so it's not like Ruby is really at a disadvantage in the article. The point of the example is to illustrate the mechanics of custom iteration (which forwarding to the encapsulated implementation wouldn't accomplish, for either language) while keeping the rest of the Stuff definition as simple as possible. But yes, a brief mention of including Enumerable wouldn't hurt.
I think the article leaves out the main difference in Ruby vs Python. Ruby is built for humans, Python is built for machines. This example used to be illustrated on Ruby on Rail's website. https://rubyonrails.org/doctrine They are philosophical vastly different languages. This isn't to say one is better or worse over the other. Just use the right tool for the job. If I was going to do anything with machine learning o…
For a lot of developers though, basking in the glory of ambiguous poetry, documented in some random funny blog, is not what puts more and broader smiles to their face while urgently trying to decipher their predecessors sensibilities, enshrined in mind bending meta-hairballs.
It is not just the job, some people just really don't like Ruby.
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…
First impressions apply to languages too. A lot of mathematicians went into AI but didn't start out with any programming experience. They dabbled in some languages and gravitated toward the one(s) they found most useful. Paraphrasing Guy Steele [1]: > It's important that when you design a language that does a familiar thing, that you do the familiar thing exactly... it's criminal that you can write 1/2 and get values…
Okay, I'll bite: how much of this is the responsibility of the language designers versus how much of it is the responsibility of the language user? If I had a junior programmer complain to me about this case, I'd simply tell them "you didn't RTFM", because RTFM'ing before you use a language is not only the professional thing to do, but vital to your accurate and correct use of the language. Sure, language designers s…
In the extreme case, take something like brainfuck. Everything is in the RTFM, but that doesn't make the language less criminal.
I like to remember that we are not here to program for the sake of programming. We are mainly solving problems. I have a problem that I know I need to solve with "a gun", and maybe I'm a novice to gun usage. After having a look at some guns, I choose the one who seems to be less dangerous and have a friendlier and more intuitive usage. When your very powerful but a deathtrap with 1000 page manual of a gun is used by no one, don't complain with "why you don't use my powerful and clearly better gun!?".
Because the key here is that this is not the 1970's anymore, when all guns were complicated. Learning by doing is the best way to learn, way better than learning by reading (https://thepeakperformancecenter.com/educational-learning/le...). If a language requires me to RTFM is at a big disadvantage with any other language that allows me to easily learn by doing.