Smalltalkers will, eventually, win. So says this old C++ programmer.
Locked
12
12
 
Administrator
|
This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh
http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
Great article. Thanks for sharing.
Not that I or most people here need convincing, but it is nice to see others voicing this opinion. > On 9 May 2017, at 08:49, askoh <[hidden email]> wrote: > > This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh > > http://blog.cleancoder.com/uncle-bob/2016/05/01/TypeWars.html > > > > -- > View this message in context: http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-programmer-tp4945895.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > |
|
|
In reply to this post by askoh
Fantastic article. Very well rounded. I particularly liked "Meanwhile the Smalltalk programmers were scratching their heads wondering what the big deal was. You see, their language was also strongly typed; but their types were undeclared. In Smalltalk types were enforced at runtime." and..."You see, the Smalltalk programmers had solved the missile problem in their own unique way. They invented a discipline. Today we call that discipline: Test Driven Development. ... You see, when a Java programmer gets used to TDD, they start asking themselves a very important question: “Why am I wasting time satisfying the type constraints of Java when my unit tests are already checking everything?” cheers -ben On Tue, May 9, 2017 at 2:49 PM, askoh <[hidden email]> wrote: This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh |
|
|
I think he forgets to mention Haskell, which is probably the reason behind the shift of Swift towards optional values (Option type in Scala, Maybe type in Haskell). You can't talk about modern type system without talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad). I don't believe the future is dynamic typing, I believe it is type inference and optional typing. There is no need to be radical about it. One great sadly forgotten example of this is Strongtalk, which was rumored to be the fastest implementation of Smalltalk ever made (I don't know how it compares to the latest Pharo VM, though) and included an optional strong type system (http://www.strongtalk.org/). Strongtalk team was bought by Sun before they could release the language and their advancements in virtual machine development were taken by the Java Virtual Machine. It is one of my dreams to see Strongtalk back into action or maybe a version of Self with optional typing, but I unfortunately lack the required skills and time to do so. 2017-05-09 10:26 GMT-03:00 Ben Coman <[hidden email]>:
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by Sven Van Caekenberghe-2
2017-05-09 5:59 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
> Great article. Thanks for sharing. > > Not that I or most people here need convincing, but it is nice to see others voicing this opinion. +1 Not only the opinion, but it is good to see somebody with such influence recognizing the merits of Smalltalk's approach. I do find myself scratching my head when looking at "problems" other developers have with their favorite toolset. Maybe I take too much for granted; I notice it every time I have to leave the smooth land of a live environment. Nice article, thanks for sharing. Regards! Esteban A. Maringolo |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by ericvm
I agree with Eric that some future
programming environments will probably provide and encourage
optional types + type inference. This doesn't necessarily contrast
with late dynamic binding à la Smalltalk.
If types are an entangled part of the language, like in virtually any statically typed programming language, it's hard to evolve them while maintaining backward compatibility with older code. This is one reason why a type system is perhaps best defined as an additional, optional component of a development environment. It is then up to the programmer to choose whether to use types and at which stage. Besides, optional pluggable type systems can evolve independently and perhaps even cohabit with others at the same time. With a sensible blend between type annotations and inference and between the language core and and a pluggable typing system, types should almost never hurt, while providing more benefits than costs. Sure, it all depends on how deeply they are enforced at all levels and phases of programming and how they are used. No doubts that in a complex and pervasive typing system as in C++, they are a real pain during the early phases of development and a burden at later stages, and make it harder to evolve software. When types are perceived simply as a means, not an end, they provide a really useful and well exploitable tool. Greetings Raffaello On 2017-05-09 16:17, Eric Velten de Melo wrote:
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
In reply to this post by askoh
On Tue, May 9, 2017 at 10:02 AM askoh <[hidden email]> wrote: This is a quote from Bob Martin of "Clean Code" fame. Enjoy, Aik-Siong Koh There is no war, nowadays you can mix languages together with ease, pick the one you prefer and do not make it a big deal.Personally I am indifferent when it comes to types, do not care if I declare them or not. Furthermore the choice of a language is 99% its libraries why bother with the 1%. If the library you want is on Smalltalk you will pick Smalltalk sadly C++ wins here with its vastness of libraries that have allowed such an ugly language to exist for so long. I do not see why its necessary for the type to be embedded in the language why not be meta data using a popular format like JSON and that will give you the freedom to limit the types or not depending on the situation. I love the smalltalk attitude of shifting the focus from the language to the libraries and IDE. A gigantic syntax like C++ is a gigantic problem. But to be fair C++ has come a long way, smart pointers have lifted the pain of manual memory management, templates have helped with implementing dynamic types. There is also a lot of talk of replacing the header system with a module system like python. So C++ is definitely evolving. The game engine I am using Unreal C++ has even further boosted the language not only by using templates to offer dynamism but also offers manual GC and a limited reflection system. However the source of the popularity of C++ has been Microsoft and Microsoft has been pushing a lot lately of its own language C# more aggressively lately by open sourcing .NET and investing on cross platform development. C++ will of course keep being the choice of top performance apps and libraries. When a new feature in C++ performance comes first because that where the language focus on. We have a different goal. So no I do not think Smalltalk will ever win on this one when it comes to performance C++ has demonstrated that its syntax though very problematic and quite annoying , it still is the No 1 choice. |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by ericvm
On 09/05/17 16:17, Eric Velten de Melo wrote:
> I think he forgets to mention Haskell, which is probably the reason > behind the shift of Swift towards optional values (Option type in Scala, > Maybe type in Haskell). You can't talk about modern type system without > talking about Haskell, Monads and Algebraic Data Types (Maybe is a monad). I don't know. I do know that I can't use something with the ridiculous compile times of Haskell or Swift. That just kills flow and productivity. Stephan |
|
|
+1 and ;-)
Am 09.05.2017 um 18:59 schrieb Stephan Eggermont: > On 09/05/17 16:17, Eric Velten de Melo wrote: >> I think he forgets to mention Haskell, which is probably the reason >> behind the shift of Swift towards optional values (Option type in Scala, >> Maybe type in Haskell). You can't talk about modern type system without >> talking about Haskell, Monads and Algebraic Data Types (Maybe is a >> monad). > > I don't know. I do know that I can't use something with the ridiculous > compile times of Haskell or Swift. That just kills flow and productivity. > > Stephan > > > > |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by ericvm
This is why three years ago a convinced Pablo Tesone and Nicolas Passerini to work on a Type Inferencer for Pharo. Now the economic situation in argentina pushed Pablo to take another grant. And this is why we proposed as a topic to new guy in our team to work on this topic. Unfortunately the system did not give him the position. For the record marcus was involved in the gradual typing phd with chilean colleague (and we do not like gradual typing) worked on PlugType an optional pluggable typer for Squeak long time ago. So if people wants to get a typeInferencer for Pharo and have money to pay a phd let me know. Or you are gifted and like types and are looking for a PhD contact me :) Stef On Tue, May 9, 2017 at 4:17 PM, Eric Velten de Melo <[hidden email]> wrote:
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by ericvm
I talked to some folks about Strongtalk at StS a few years back, and they told me that in order to achieve the speed improvements, they had to throw away type information. Basically, they tried to prove that static typing was faster, and proved the opposite. I'd like to have that confirmed; it would challenge "conventional wisdom" on static typing. -Steven
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
On 09/05/17 21:22, Steven R. Baker wrote:
> I'd like to have that confirmed; it would challenge "conventional > wisdom" on static typing. I don't recall details but I have read that no static type information was actually used for "speeding up", it was all PICs etc. So yes, an interesting fact. However - I don't think you can "prove" anything in this area. The fastest dynamic lang implementations like LuaJIT, V8 etc are still a fair factor away from the performance of C, C++, Nim, Rust (and similar statically typed langs and their compilers). In other words, the things you can optimize dynamically in an advanced runtime (say a tracing JIT like LuaJIT) haven't *yet* proven to overtake the raw advantage of all possible compile time optimizations. In theory a warmed up sufficiently advanced VM should beat statically compiled code - simply by the fact it has more information at hand. But... it hasn't been observed yet AFAIK. And even if it happens - in many areas where you need raw power you also have: - Memory requirements - Consistency in speed ...and a VM like say the JVM tend to fail hard on both accounts even if it can approach C++ speeds when sufficiently warmed up. regards, Göran |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by Stephan Eggermont-3
Let me add that I am perfectly happy with the system given the type and size of applications I do write and maintain. And having flow is #1 criteria for enjoying my work. Phil On Tue, May 9, 2017 at 6:59 PM, Stephan Eggermont <[hidden email]> wrote: On 09/05/17 16:17, Eric Velten de Melo wrote: |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by Stephan Eggermont-3
On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote:
> I don't know. I do know that I can't use something with the > ridiculous compile times of Haskell or Swift. That just kills flow > and productivity. You could hop onto an office chair and engage your colleague in sword fighting. That's a plus! :-) Pierce |
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
Just to remind people here that all languages with long compile times can be avoided live coding style through the use of dynamically linked libraries known as DLLs on windows, shared libraries on linux (*.so) and macos (*.dylib) . Also Swift in particular comes with a live coding environment called "Playgrounds" which is also very flexible. Haskell do not know if they have something similar to Playgrounds but I will be surprise if they do not have something at least inferior. All languages support DLLs including ours. Live coding is actually super easy to implement and believe me I was sceptical about it at first and if I had read this post I am making now I would call me crazy. But after implementing live coding in python, C and C++ , now I am a believer. Of course the real question here is if its that easy why people do not use it . From what I have found out, it has not occurred to them as it did not occur to me. Why C++ coders still endure long compile times when they could test code in an instant through live coding ? Well in games C++ live coding is actually very popular, so some are already aware of the huge advantages of live coding. I think this is an advantage of Pharo , that introduces to live coding, a so simple idea yet so essential without you having to think about it yourself or be already aware of it. With other language you will have to find a tutorial or article that mentions this ability. Another shock for me is how simple it is to implement an image file format for other languages. The shock was that the OS already uses image files like pharo image that calls them "memory mapped files" they are used for sharing memory which in turn is what is used for DLLs. The advantage over the pharo image is that it crash prone, because it is handled by the OS and not the language or the VM. Which means that even if your app crashes the image is still saved and you lose no live data which is not the case with pharo image. The disadvantage is that of course they are not OOP friendly as the pharo image is and they are not language specific as pharo image is. Again I would not have known any of this if I had not been playing with shared memory as an IPC and I also see coders rarely if ever mentioning them. On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]> wrote: On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: |
|
Administrator
|
Kilon: This is revelation to me. I am enduring 10 minute turnaround for every edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web server update. How can I get that shortened to 10 seconds say? What links can help? What search terms to google? Thanks, Aik-Siong Koh
|
|
In reply to this post by kilon.alios
Kilion,
In Haskell (a language that I love, just as Smalltalk) you have the REPL. The workflow is, while you are working on the project, you periodically load that file into the REPL and check. After that you compile. Haskell works with a strong type inference feature, however most Haskellers will say that the best practice is to annotate all functions. Also if you are on macOS you have: http://haskellformac.com/ which is awesome, really a great piece of software. There was even a project called Kronos that was essentially the same as IPython but with a Haskell kernel I don't know the status of that project as of today, I really never used it. just my 2c best Nacho
Nacho
Smalltalker apprentice.
Buenos Aires, Argentina.
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
In reply to this post by askoh
There is a Java REPL. You could Google that. There's also a some kind of commercial hot/live compiler tool called "JRebel". Haven't tried it (don't code Java). On Wed, May 10, 2017 at 4:29 AM, askoh <[hidden email]> wrote:
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
Or BeanShell or Groovy or Spring-Shell Example app I am using (and extending) for Hadoop work: https://github.com/sequenceiq/ambari-shell When one looks inside a command, this is something easily achievable with pragmas. There is nothing extraordinary in these pieces of tech ("pas de quoi casser trois pattes à un canard" in French). But we need our own house in order on the CLI. GSoC time! Phil On Wed, May 10, 2017 at 7:38 PM, blake watson <[hidden email]> wrote:
|
Re: Smalltalkers will, eventually, win. So says this old C++ programmer.
|
|
Hi kilon, Some weeks ago I tried the C live programming technique for the Ludum Dare. It works very well. For that occasion I wrote this short article https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world/a-diabolical-game-for-a-diabolical-experiment . The game ended pretty well in my opinion: https://ldjam.com/events/ludum-dare/38/smalcoded-a-small-eco-destroyed-world .
I work for a video game company that is using Unreal Engine 4, we do not use the C++ live coding features. I do not like the way that they implemented live coding, and the bindings for their Blueprint visual language. We all hate the long compilation times of UE4, the fact that they use their own undocumented makefile system which is using a bunch C# files for building their project. We also do not like the fact that from time to time, we see that we are missing some #includes because of the unity builds that are done by the unreal build system (merging several .cpp before compiling them).
The biggest problem of these other language language is the lack of reflection information at runtime. The second other problem, is the lack of #become:, for swapping objects when their data layout changes. Elf files, PE files (.exe, .dll) and other executable formats are process images with a symbol table and relocation metadata. If the operating system allowed to modify in an easy way the symbol table of the current loaded process, it could be even cooler. In Linux, dlopen is implemented in terms of open() and mmap(). Best regards, Ronie 2017-05-10 16:48 GMT-03:00 [hidden email] <[hidden email]>:
|
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |