21–30 of 80 posts
Or how about in Clojure? (map (partial reduce +) (partition 7 7 daily)) Edit: Possibly that should be partition-all from seq-utils to sum the remainder days if the length of daily isn't divisible by 7.
> Possibly that should be partition-all from seq-utils As of June 20th, there is now an optional padding argument in clojure.core/partition.
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
Some day, something like Python will be the fast low level language, there will be new slower languages that are easier to use than Python, and C will be a memory. There are Smalltalks that ditched (in one case all) their "primitive" methods written in C against the VM internals because the JIT compiler turned out to be good enough. (Agents for the all case. VisualWorks also lets much of the Dictionary functionality…
Ruby in particular is basically Smalltalk + Lisp for regular people - it's taken a good chunk of the concepts and packaged it in a way more people are happy to work with.
First time I read about Scheme I was fascinated. Until I played with it a while and put it away and promptly went back to lower level languages (C, Pascal and M68k assembler at the time) because the syntax (or lack of ...) was just too alien for me.
Same with Smalltalk.
Yes, I discarded them over syntax. Speed never entered the equation - I dropped them before I got to evaluate performance.
Ruby is the first language I've worked with that could do justice to a lot of the concepts from Smalltalk and Lisp.
I very much doubt Lisp and Smalltalk has much hope of wider use than they see now - most of the important features are being added to other languages, and the remaining ones are not seen as useful enough by most developers to be worth the painful syntax.
The computational models and the work done on compiling them efficiently will contribute a lot though. Most Ruby implementations in the work and several Javascript implementations are all over PIC's and other concepts take from the Self project, for example.
weekly = [sum(daily[j:j+7]) for j in range(0, len(daily), 7)] While I appreciate the general sentiment that high-level languages will take over the world, there is very little that's new in this article and I am not impressed by the showpiece Python code from the article. For loops are the future?
Earlier quoted context omitted.
That's pretty unreadable for someone who doesn't know clojure.
That's pretty unreadable for someone who doesn't know clojure. And that Python is pretty unreadable for someone who doesn't know Python.
Earlier quoted context omitted.
Static typing hardly replaces unit tests. And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer. If it were true, why would Java programmers use JUnit?
As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all. Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that deman…
I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too!
In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved.
I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.
I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? Wouldn't you then lose a great deal of the leverage of using a freedom language?
Earlier quoted context omitted.
That's pretty unreadable for someone who doesn't know clojure.
That could be said for any language. It's just that the first language someone usually learns borrows more from algol than from lisp. This leads to the idea that Python/Ruby/PHP/Javascript are easier to learn than Clojure/Common Lisp/Scheme.
The only reason to write in a language like C or Java today (over Python) is speed. And there are a very limited number of applications that require that sort of speed. There's no question that Linux should be written in a low level language, or a high-performance chess bot. But I'm incredulous when I see anyone write a website in even the relatively high-level Java. So, the author is right that we're getting more Py…
C is portable assembly, I see no reason for it to disappear, and actually it would bother me to have to write low-level stuff in python.
Earlier quoted context omitted.
As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all. Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that deman…
No, static types don't catch everything. But they are desirable if they catch anything at all. I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too! In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved. I can imagine development methodologies that demand you statically type everything before you release…
Is this a deliberate troll? Failure of reading comprehension? Where do I ever advocate static types as a replacement for Unit Tests? Why would a Smalltalker ever do that!?
I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release?
There's a big difference between inserting a bunch of tags like at the end of the development cycle, probably guided by a coding tool, possibly using Hindley-Milner type inference to automate part of the process, and rewriting. (See Haskell)
Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax? Please give an example that would require something as extensive as a rewrite.
EDIT: To clarify, Strongtalk type annotations are completely optional. Take almost any code, remove the type annotations, and it will run exactly the same. They are also always just the Class Name. In Strongtalk as in Smalltalk, evenything is an Object, so all types are simply Class Names. No complex types at all.
Earlier quoted context omitted.
That's pretty unreadable for someone who doesn't know clojure. And that Python is pretty unreadable for someone who doesn't know Python.
That specific python example is very readable for someone who understands basic math (sets and functions). The clojure example, not so much.
Earlier quoted context omitted.
No, static types don't catch everything. But they are desirable if they catch anything at all. I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too! In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved. I can imagine development methodologies that demand you statically type everything before you release…
I hear you, but come on now, static types as a replacement for unit tests? Is this a deliberate troll? Failure of reading comprehension? Where do I ever advocate static types as a replacement for Unit Tests? Why would a Smalltalker ever do that!? I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? There's a big difference between inserting a bunch of tags like…
Whoa, what are you talking about? Ironically, I think you're the one failing at reading comprehension. Read the thread. Clearly my "static types as a replacement for unit tests" comment was referring to the post I'd responded to initially. It had nothing to do whatsoever with what you said. I was essentially acknowledging your point, but saying that some people seem to advocate static typing for everything. Calm down bro.
Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax?
Actually, no I didn't, and yes I'm unfamiliar with it ... that's why I asked you for more info.
the rest of what you said
This is all interesting to me. I'm only lightly familiar with Smalltalk and Strongtalk. I was asking for clarification because I really wasn't sure I knew enough about it. Again, no trolling intended ... no need to be defensive.