Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I installed Pharo 1.4 and tried to read "Pharo by example".
Unfortunately, the book and the Pharo image were totally out of synch with each other: menus were different; classes used as examples were not there e.g; BouncingAtomsMorph class.
It is a pity. Maybe one should use a specific Pharo version to learn and another to get up to date...can anyone help?
First of all be sure to complete Prof Stef's tutorial, it gives basic knowledge. You can start the tutorial by executing
ProfStef go.
in a workspace. Just type it in the workspace, select it, right-click, Do it
There is also a Pharo collaborative book that has interesting things. And there are Pharocasts that can help you to learn something interesting.
Also you can ask questions here on Stack Overflow an tag them with pharo or smalltalk if it's more general and people will help you out.
As said by #Sharphawk, there is an image to be used with the book, available from the homepage. It's a bit old by now, but it should be in sync with the book.
Pharo simply evolves too fast for us to keep up with the book (there are still many chapters under progress), so with recent images you'll have to adapt and discover a bit by yourself. Fortunately there are a lot of other ressources where you can get help: here of course, mailing lists for the book and for Pharo itself, the #pharo-project IRC channel on irc.freenode.net, the books & screencasts pointed to by #uko, etc.
From experience, Smalltalk is much easier to learn with some exploration and mentoring
For absolute beginners, the following is a very recent practical and hands-on tutorial, covering just the basics to get you going:
http://ceronio.net/2017/07/first-steps-with-pharo-smalltalk/
As your question is a bit vague (understandably), and I do not know your background or your needs, I'll try to give a short overview over Pharo, so that you know where to look for, as you gain more experience and your needs evolve.
Language Basics
As Uko has pointed out, if you are new to Smalltalk the best way to get started
is to follow Prof Stef's tutorial. This will get you familiar with the core aspects of the language. For quick reference, you can use the Pharo Cheatsheet.
Basic Tooling
After you have completed the tutorial, you should familiarize yourself with the tools so that you can work effectively in Pharo. Vital tools, as you probably already know, are the Class Browser, the Inspector and the Debugger.
Learning from Code Examples
The Class Browser has a lot of useful features, in particular it allows you to search the system for method and class references, pointing you to concrete code examples. You can right-click on any method and then choose "Senders of..." in the context menu. Similarly, for classes, you can look for references (Analyze -> Class Refs). This will tell you how particular classes and methods are used, and more than often, will get you faster to the information you need.
Another indispensible tool is Spotter (shift-enter), which provides an easy to use interface to browse the system (for classes and examples). But you'd have to use recent Pharo version.
Ecosystem Overview
That being said, the Pharo ecosystem is quite huge and it will take you some time to get the most out of it (I have been working with Pharo for quite some time now, and there are many things I still have to learn).
Depending on your needs, Pharo has a lot to offer:
Roassal (for software & data visualization)
Glamourous Toolkit (GT) (including Spotter, the Debugger, and the Inspector).
GT allows you to customize all of its tools. For instance, you can customize the inspector very easily to have domain-specific views for your objects. Lots of built-in libraries, such as PetitParser, have customized interfaces that allow you to work more effectively with objects.
Morphic for writing GUIs. There is also Spec, a DSL built on top of morphic, which allows you to describe user-interfaces.
Monticello for version control and building packages that can be deployed to other images.
SUnit for writing testcases.
Roassal is very different from Morphic as it is tailored for rendering all sorts graphs in nice layouts (while it is possible to do that in Morphic as well, you'd have to write a lot of code). Also Roassal uses Vector Graphics, Morphic is raster-based.
If you want to write GUIs or a game, I'd stick to morphic. If you have to visualize data, use Roassal.
An excellent introduction into the core concepts of Morphic is given by Maloney (the originator of Morphic). Some class names have changed, but you'll figure it out.
There are also different ways in doing event handling in Morphic. One way is to override methods (like you are used from other object-oriented GUI frameworks), another way is to "route" events to methods. I have used both methods, and I'd pick the first one for simpler applications.
Start with a simple project
My advice would be to start with the very basics, best with a small project, for instance a game like Snake. Add things as you learn and if you are stuck, feel free to ask questions on stackoverflow. Also, there is the Pharo mailing list.
I found that the Pharo / Smalltalk community is very welcoming.
My last advice would be: Keep things simple. It's not always easy to do, but Smalltalk is a great environment to learn this principle. You'd also want to look at Kent Beck's Best Practice Patterns if you are looking for ways how to organize your code.
Have fun!
Edit: Holy thread resurrection! I just realized that the question is over 4 years old. Well, maybe this post if some help to other newcomers.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I've been wanting to get into a pure-OO language for a while now, but I'm put off by the fact that they all seem to demand an IDE and I can't find any good tutorials that aren't in video format.
I'm happy to use an IDE later, but I don't want to learn the language through one. What I'm looking for is a simple console interpreter or command-line compiler such as gcc, ghc, ghci and the python IDLE (yes, it's an IDE, but it's so minimalist that it may as well just be a commandline interpretter). I find that I learn a language faster, better and more comprehensively when I'm not trying to grapple with an IDE at the same time. So please, don't tell me that squeak is the only way to do it :P
I'm also looking for tutorials that are presented textually rather than visually. Again, I learn faster when I can stare at a page and read someone's sentance over and over tossing and turning it in my mind rather than having to pause a video, take it back 10 seconds, press play, do it again, and again, and again.
I'm interested in various languages with various degrees of OO-purity, and I plan to learn them all at some point. Any of the smalltalk dialects interest me, Self (an extreme prototype-oriented version of smalltalk (Very interesting, the more radical the better imo)), strongtalk, vanilla smalltalk (or some implementation which is as vanilla as you can get).
I'm interested in Eiffel as well, the code snippets I've seen make it seem very elegant and I've read that it actually was very innovative (introduced code-contracts and other such things). However I would give preference to a language from the smalltalk camp over one from the Eiffel side because Eiffel at face value seems to be a hybrid between OO and imperative programming. Similarly I'd rather avoid Scala (Hybrid OO and functional) and other hybrid languages. So no C#, Java, C++, D, python etc etc etc. I'm not dismissing these languages because I believe they are bad, it's just that I'm setting out to learn pure-OO and those languages are hybrid OO: Not really what I'm looking for.
Also, would anyone be able to recommend the official books? For smalltalk there's the "Blue book" AKA "Smalltalk-80: The Language and its Implementation". And for Eiffel there's "Eiffel: The Language". I ask because in my experience you can pick up so much by reading books written by the author of the language (see K&R the C programming language), and by reading books in general.
So yes, my questions: What pure-OO language would be good to start off with? How would I go about learning it without having to use an IDE? And is there an associated book written by the language author(s)?
It is not helpful to learn Smalltalk as just another language. You would be missing the point entirely.
Smalltalk's graphical environment is not just an IDE. The core of the system is simply objects. The interface provides various ways to create objects and interact with them. The language is just a convenient way to create messages to the objects. It is secondary to the objects themselves.
In other OO languages, you write your program, then you run it, which creates objects in memory. Not so in Smalltalk. You create objects in memory (e.g. class objects) and then send messages to e.g. add methods. But a class object is only created once, not every time you "run your program".
There is no such thing as "your program", in fact. There is no "main". It's just a world of objects, some longer-lived, some temporary. In fact, in the system there are objects that were created 30 years ago. Literally. The objects are just frozen to disk as a memory dump (a file which we call "image") and unfrozen later (possibly on a different machine).
That image, the world of objects, is the primary artifact in Smalltalk. There is a sources file, yes, but that's just a database of text snippets to not take up so much RAM. You cannot edit this file by hand (objects in the image use absolute file offsets into the sources file). You cannot re-create the system from the sources file - the system was bootstrapped a long time ago and from then on only modified.
It's true that superficially the Smalltalk GUI looks just like another IDE. No coincidence - Eclipse was originally written by Smalltalkers in Smalltalk. But there is the crucial difference that in regular IDEs you just manipulate text files. A text editor is a valid alternative for that. In Smalltalk, the GUI manipulates objects in memory. A text editor can not do that.
And as for what Smalltalk to use, I would recommend Squeak. Very friendly community, very nice environment, and subscribing to the original Smalltalk vision of creating a great personal computing environment for everyone.
As someone who has went through process of learning Smalltalk (at least to a decent degree), I can say that you are taking harder and riskier path, in a sense that some things may take much longer to clear up, or never actually do.
But, if you insist, you can download GNU Smalltalk, for which no GUI is a norm. It also contains all sources of the system written in Smalltalk in a chunk format and you can open your text editor on them and enjoy while slowly reading through the guts of the system.
You could also startup any other Smalltalk, like Pharo, and just stick with a workspace window - this is your equivalent of command line interpreter.
Pharo also includes ProfStef quick interactive tutorial on Smalltalk, which combines text instructions and evaluating Smalltalk expressions.
As for reading, there is Pharo By Example - free book that you can browse, download or buy hardcopy.
There is also a collection of free books in which I would recommend "Smalltalk-80: The Language and its Implementation" By Adele Goldberg and David Robson, if you are interested in the innards and detail of the language.
Late David N. Smith Smalltalk FAQ is also exelent resource.
So, there you go. And take advice, and give in to the Smalltalk IDE as soon as possible, since it makes understanding of Smalltalk much, much, faster.
Richard Gabriel gave a talk recently about a paradigm shift that occurred in the programming language community in the early 90s. He claims that most experts today are incapable of understanding many of the papers from the 80s. He has evidence to back this up. This was the first time he gave the talk, and he expects to give it many times, so I imagine that many parts of the talk will change. At first, he described this paradigm shift as engineering -> science, but then he described it as system -> language. I think that describing it as a shift from systems thinking to language thinking is a better description.
Richard Gabriel is a Lisp guy. (I'm a Smalltalk guy). Lisp is like Smalltalk in that there isn't a clear boundary between the language and the library that it uses. Arithmetic and control flow are in the libraries, not the language. (Well, Lisp has some in the language and some in the libraries, while Smalltalk has it all in the libraries, except that the compiler cheats and hard codes some of them, so there isn't really much difference in the end.) In Lisp, a program is an S-expression, and editing programs is editing S-expressions. In Smalltalk, a program is a collection of objects, and editing programs is editing objects. When you are programming, you are building a system, and you program with the system.
System thinking is different from language thinking. Language thinkers want a precise description of a language. They want a book that describes the whole thing, or (if they are academics) they want a formal semantics for the language. But system thinkers know that as soon as they start to use the system, it will change. They want to understand how the system works, but are prepared to look at the system itself to figure out the details.
These are two ways of thinking, and there are advantages and disadvantages of each. Smalltalk is a wonderful example of systems thinking. I think all software developers should know at least one system that exemplifies systems thinking. Lisp is good. Forth is another old example. Naturally, I think that Smalltalk is great and am happy to help people learn it but I think the importance of learning systems thinking is more important than the particular system you learn.
Unfortunately, learning a system is harder than learning a language. You have to do more than just learn the syntax, you have to learn the libraries, the patterns of naming and of coding, and usually the tools. (Which, if this is a system, are extensible.) That is one of the advantages of language thinking. But systems thinking has long-term advantages, because once you taylor the system to your needs then you can become very productive.
To lean smalltalk syntax, you need to read ONE page of text (see Syntax section on wiki http://en.wikipedia.org/wiki/Smalltalk).
Now, to learn a smalltalk libraries and how to use them, you need to use browser not the text editor, otherwise your will just waste a lot of time.
I think that it is like factor of 10 difference in time, between trying to understand some code by reading in textual format and navigating it using browser and! debugger.
In smalltalk system a living objects could tell a lot about themselves and help you learn how to use them much faster than if you look at it as a static chunks of text, because you won't grasp the idea at all.
I've been playing with Squeak Smalltalk (and its close cousins, Pharo and Cuis) for a while now. There's no better way to learn Smalltalk than by using the system already provided.
I've devised a series of short youtube tutorials ranging in length from 50 seconds to 15 minutes that show how to take advantage of Squeak's ultra-cool features within a few minutes of first starting the system.
In fact, the very first line of code demos the OOP-ness of Squeak. Squeak from the very start
Python is a pure OOP . Actually this is an easy mistake that newcomers make when they come to python.
Python like smalltalk follows the mantra "Everything is an object". So everything inside python is an object, including built-in types. The difference is that python unlike smalltalk and Java does not force OOP as it allows procedural programming. And this is the trap, it easy to assume that makes python less OOP , but being a snake, is so devlish that does not tell you that even functions are objects ;)
http://www.linuxtopia.org/online_books/programming_books/python_programming/python_ch10s04.html
Going back to smalltalk its IDE is the huge deal here, contrary what other smalltalker may believe. If you like me are heavily disappointed with how non flexible IDEs are you are going to love Squeak's IDE. The IDE goes a great deal making easy to navigate through all the libraries and making you understand what , where and why , something happens. I cant see the benefit of using a text editor. But you can, with file ins and file outs. But doing so you cripple smalltalk into becoming as efficient as other programming languages ;)
I am only studying squeak and pharo for a week now but even for me as a beginner the benefits of the IDE is obvious from the first minute.
The fact that code is fragmented into easy to digest methods, those methods grouped into protocols , protocols grouped to our familiar Classes and Classes grouped to packages. Hence the code is so well organized that I never feel lost, everything belongs somewhere, everything is just a click away, everything is inspectable, browseable , you just select right click and sends you there. And it shows you exactly the code you need rarely more than 10 lines long. This is the IDE. Why would you prefer a text editor that will expose to information that you don't need , don't care and is likely to confuse you ?
Then everything is inside a single image , not a collection of files, your code, your libraries, system libraries , even the language itself. Everything is at your grasp, waiting for you, begging you to test, modify it, use it and abuse it. You are part of the language and the language is part of your, if something does not fit your thinking, change it. This is the IDE. Why you want to go back to the disconnected way of files and folders ?
Then you are start being afraid with all this power, all this flexibility its not unlikely that you will do something that could completely destroy the language and the libraries. Its possible , mistakes can and will happen. Again the IDE jumps in offering you a hand of help, every change is stored in a local cvs system, every change is categorized, stored and monitored any time. No lousy undos and any kind of other nonsense . What you get is old , mature well tested version control. You can change back exactly what you want any time, nothing is lost, no mistake is irreversible.
And if you don't trust you hard driver , the vcs extends online to squeaksource . And does it let you at the mercy of command line ? Hell no . You are offered the simple yet efficient Monticello browser , which will make sure you install and unistall with no conflicts .
And of course you don't want your software to have bugs , do you ? Unit Testing tool is offered to make sure your code is reliable , stable and does exactly what you want how you want it. Again a beautiful yet brilliant GUI is utilized to make complicate tasks a button away.
And because none is perfect , there will be time you will come against the dreadful error. Are you left alone ? You guessed right , a tool again is offered. The debugger. You don't need to call it, you don't need to setup it , you don't even need to figure out how it works. Like all other tools, is simple in design yet sophisticated. Not only it will spot the error , not only will tell you what you did wrong , not only will navigate through back to most basic language elements that trigger the error offering a unique perspective on how exactly the language behave like nothing I have seen before, it also allows you to do live coding. Live coding is the ability to code a program while its code runs. Isn't that impressive and infinitely useful ?
Finally , maybe you are one of those people impossible to please, maybe you still find flaws , omissions and thinks you simple don't like. The IDE is written in smalltalk , smalltalk is written in smalltalk , and the IDE can edit itself and the language, there is nothing you can't change besides some very basic functionality of the language and the VM that is compiled C. And you will guess right if you think you can use all the above tools to do exactly that.
And the tools don't stop here , smalltalk might be not that popular as other languages but it has been here for a very long time and it has some very enthusiastic programmers that love to contribute. And frankly with such an amazing IDE and such a well designed language , while with other languages contributing to them might seem a challenge, in case of smalltalk the challenge is to resist the temptation not to contribute as the IDE makes it so easy.
By the time others still code you will finish your code and actually understand what have you done and why. Thats not a small thing at all . I wish Python had such a good IDE or any other language. But the only thing that comes abit close, from my experience , is Delphi. And even in the case of Delphi I still prefer squeak and pharo.
What I find annoying about other IDEs is that they are not IDES at all, they are nothing more than glorified editors, locked, non flexible , non editable (Unless you are willing to use another programming language and navigate through tons of source code) . Squeak , Pharo and all other smalltalk dialects offer a real elegant IDE offering you really useful tools. Other IDEs better take a deep a look at smalltalk and really understand what it means to be an IDE.
Saying all those good things, smalltalk is far from perfect. And I think its biggest weakness and flaw is lack of some enjoyable and useful documentation that can help beginners jump in head first. Squeak By Example as well Pharo By Example has been a big disappointment for me. They both are still two extremely important books that provide a extremely valuable insight in both platforms , but the quality of documentation is from mediocre to bad at times. The main reason is both books follow a non noob friendly approach. First they send you deep diving in the IDE , introducing you from chapter 1 , to debugger and even unit testing !!! For me this a big mistake, and even though I am far from new to programming had to struggle to follow up what was explained. Then the book itself , lets a lot of unanswered questions. For example the explanation of instance vs class variables is not enough, I would prefer several example that not only show the how but also the why . Several areas of the book are also full of gaps or just hard to follow.
My life got a lot easier when I found this link http://stephane.ducasse.free.fr/FreeBooks.html and from there I downloaded "Smalltalk by Example" which unlike the other book not only it does what it says in the title but makes no assumption on who you are and what you know. I can only highly recommend it. I read that the other books there that are offered freely are very good as well, I will certainly download and read all of them eventually.
Alot of help has been also #squeak at irc.freenode.net, people there has been answering my questions and helping me understand.
Squeak wiki, is ok but not enough, its also not very well organised, and I dont like that comments and discussions appear inside the wiki documentation. So documentation generally can be abit of a struggle for the begginer and certainly Smalltalk IS NOT AN EASY programming language to learn. I hear many smalltalkers say otherwise and I could not disagree more, when I compare smalltalk with python is like night and day. BUT ! Once understand smalltalk , it become much easier to program in it then any other programming language I have learned so far, and I have learned most of them. So in the end I think Smalltalk is a clear win , I also love the FFI library that lets you call any C library with ease, which unleashes serious power for smalltalk.
I dont think you need to learn the language first and then the IDE, its actually a very bad idea for the simple fact that the IDE helps you understand the language and its libraries and any type of code in it. Language and IDE is like brother and sister, yin and yang.
Well, if you decide to learn Eiffel a good book would be "Object-Oriented Software Construction" by Betrand Meyer (he created the Eiffel programming language).
The book provides great insight into object-oriented design using Eiffel. In my humble opinion is one of the best OO books around.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In short I'm creating a 2D mmorpg and unlike my last "mmo" I started developing I want to make sure that this one will scale well and work well when I want to add new in-game features or modify existing ones.
With my last attempt with an avatar chat within the first few thousand lines of code and just getting basic features added into the game I seen my code quality lowering and my ability to add new features or modify old ones was getting lower too as I added more features in. It turned into one big mess that some how ran, lol.
This time I really need to buckle down and find a design that will allow me to create a game framework that will be easy to add and remove features (aka things like playing mini-games within my world or a mail system or buddy list or a new public area with interactive items).
I'm thinking that maybe a component based approach MIGHT be what I'm looking for but I'm really not sure. I have read documents on mmorpg design and 2d game engine architecture but nothing really explained a way of designing a game framework that will basically let me "plug-in" new features into the main game.
Hope someone understands what I mean, any help is appreciated.
If you search for component-based systems within games, you will find something quite different to what you are actually asking for. And how best to do this is far from agreed upon just yet, anyway. So I wouldn't recommend doing that. What you're really talking about is not really anything specific to games, never mind MMOs. It's just the ability to write maintainable code which allows for extension and improvements, which was a problem for business software long before games-as-a-service became so popular and important.
I'd say that addressing this problem comes primarily from two things. Firstly, you need a good specification and a resulting design that makes an attempt to understand future requirements, so that the systems you write now are more easily extended when you come to that. No plug-in architecture can work well without a good idea of what exactly you hope to be plugging in. I'm not saying you need to draw up a 100-page design doc, but at the very least you should be brainstorming your ideas and plans and looking for common ground there, so that when you're coding feature A, you are writing it with Future feature B in mind.
Secondly, you need good software engineering principles which mean that your code is easy to work with and use. eg. Read up on the SOLID principles, and take some time to understand why these 5 ideas are useful. Code that follows those rules is a lot easier to twist to whatever future needs you have.
There is a third way to improve your code, but which isn't going to help you just yet: experience. Your code gets better the more you write and the more you learn about coding. It's possible (well, likely) that with an MMO you are biting off a lot more than you can chew. Even teams of qualified professionals end up with unmaintainable messes of code when attempting projects of that magnitude, so it's no surprise that you would, too. But they have messes of code that they managed to see to completion, and often that's what it's about, not about stopping and redesigning whenever the going gets tough.
Yes, I got what you want...
Basically, you will have to use classic OOP design, the same one that business software coders use...
You will first have to lay out the basic engine, that engine should have a "module loader" or a common OOP-style interface, then you either code modules to be loaded (like, as .dlls) or you code directly within your source code, using that mentioned OOP-style interface, and NEVER, EVER allow a module to depend on each other...
The communication, even inside your code, should be ALWAYS using a interface, never put "public" vars in your modules and use it somewhere else, otherwise you will end with a awfull and messy code.
But if you do it properly, you can do some really cool stuff (I for example, changed the entire game library (API that access video, mouse, keyboard, audio...) of my game, in the middle of development... I just needed to recode one file, that was the one that made the interface between logic, and game library...)
What you're thinking about is exactly what this article describes. It's a lovely way to build games as I have blogged about, and the article is an excellent resource to get your started.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 2 years ago.
Improve this question
I try to be very cautious with this question. There are at least three different web-development frameworks available in Smalltalk. The most prominent seems to be Seaside but there is also AIDA/Web and Iliad.
They seem to be very similiar, but this impresson may be wrong. I wonder who has tried the different tools and can share the pros/cons of the different packages.
A more concrete question would be, do yo know of let's say any software in the bookkeeing area which has choosen to use either of the three (or other) web development frameworks.
Here's one other question. What about maturity and compatiblity. Which framework can one judge as the "most" stable?
99% of my practical experience is with Iliad, so my comparison is primarily about how I got to choose Iliad instead of the others.
Seaside. Tried it first, it is the most known and the first you stumble in. I found it hard to understand (as always, no matter what you use, when it gets to real implementation you always run into issues that fit badly with the general theory), there was little documentation around and the community seemed to care little about telling n00bs how to grow up. I eventually dropped it to check Aida. You find them here: http://seaside.st/ and on IRC at #seaside
Aida. I really liked it, as Janko is extremely patient and supportive. It is large, though. I decided to use it, when I was to start implementation for our project and it was only by chance that I ran into Iliad a few days before starting. You find Aida here: http://www.aidaweb.si/ and on IRC at #Aida
Iliad. The main reason I chose it was that I had just dropped Squeak and switched to gnu-smalltalk. gst seemed to have a lot of ongoing activity on Iliad, so I reckoned I was probably going to get a better assistance with it. It is much smaller as a concept (though it does absolutely everything) and I had very little trouble in getting started and in tweaking it to what I needed for. It also proved to be well managed, as I went thru 3 releases without ever being in trouble with what I had already deployed. You get answers to questions usually in 12-24 hours max, which is fine for me. You find Iliad here: http://www.iliadproject.org/index on IRC issues are usually channeled on the #gnu-smalltalk channel
What we are doing is a GUI for a PostgreSQL database used to manage a large multimedia dictionary, that in turn produces content (among others, for KDE-edu). I have no notion of booking apps in general, so I cannot answer to your question properly.
Yet, speaking as an analyst, a booking app is mostly a DB with an online GUI, so I see no reason why you could not make it. Much will depend on how easily your db can translate into objects. You could use a RDBMS, as we did, and design tables to map objects, or use an OODBMS. Both solutions have pluses and minuses, none of them is going to have an impact on your choice of framework, I'd say.
My suggestion is that you take a month or so in making experiments and see what better fits you. I don't think there is a tool that fits everyone, we are all different and what is easy for me may be hell for someone else (and the other way round, obviously). So try your car before buying it ;)
I would not invest too much time in studying the general theory. Using a smalltalk framework is going to turn upside down the way you make a web app anyway, and your first contact is going to be full of "false friends" you inherit from previous mindsets. Your best asset is definitely going to be "how quick can I grasp what they tell me", and this is largely an individual thing, depending on you and on who you bump into. So I'd really suggest you get your hands dirty BEFORE reading too much theoretical stuff.
These frameworks are all quite different and have different goals. It would be interesting to collaboratively create some kind of comparison.
As an author of Seaside I can provide the key properties of Seaside only:
Seaside makes building web applications feel like composing traditional GUIs: components can be freely composed and reused. Sequences of components are defined using a sequence of Smalltalk statements.
Seaside has a layered architecture, providing you with high-level abstractions (components, control flow, callbacks, HTML generation, JavaScript generation, ...) over low-level concepts (HTTP, Request, Response, URLs, HTML, JavaScript). If you need to, Seaside gives you full access to low-level constructs too.
There are two Seaside books to help you get started: Dynamic Web Development with Seaside and Seaside Tutorial.
Seaside provides a tight integration into various state of the art web technologies: JavaScript (JQuery and JQueryUI), SVG, RSS, HTML5, Comet (Server-Push)
Seaside runs identically on most today's Smalltalk platforms: Pharo Smalltalk, Squeak, GNU Smalltalk, GemStone Smalltalk, VW Smalltalk, VA Smalltalk, and Dolphin Smalltalk. It is supported by all vendors of Smalltalk platforms.
Seaside provides industry proven open-source components for meta-modeling (Magritte) and content management (Pier).
Let me introduce some strengths of Aida/Web too, because as its author it would be hard to me to compare with other two frameworks. Aida strengths are:
RESTfull URLs
MVC support, every domain object can
have its own RESTfull URL, each domain class has its own web presentation class,
Integrated AJAX and Comet
support, you don't see any difference
between a traditional and Ajax
programming anymore,
Tree-like control flow for GUI-like
control flows, without need for
continuations
Building web pages programatically by
composing from components/elements
(no template based)
Scalable in complexity and performance
Integrated security with access
control and users/groups management
Ported to most Smalltalk dialects:
Squeak/Pharo, VisualWorks, Gemstone
GLASS, Dolphin, Smalltalk/X
Prime and most fresh example of Aida at work is this year Smalltalk Google Summer of
Code site.
This is the is a nice example because it was developed it in maybe a week in
total, together with a development of GSoC process in parallel and in
the same time managing that process as an admin. This site is actually
an extended Aida/Scribo CMS, with strong use of so called scriblets,
that is, dynamic web "includes" directly into the content of the site.
That way I was able to very quickly support the new ideas which come
during the evolving GSoC process.
Well, Suixo uses Seaside. Take a look at the GSoC projects we defined. Its more ERP than bookkeeping, and currently focused on healthcare.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have noticed I do not code as much as I use to. Today I dedicate more time to analysis and design, then I communicate that design to programmers. Then they do the coding. This has affected my coding productivity, because I must consult references and rely on intellisense. Things are becoming more complex everyday
Now, here is the irony. If I were to hire a programmer and ask him/her to sit in front of a computer, I may ask to do some coding and I would check abilities. I would evaluate them based on their use of memory vs. consulting references. Maybe I will prefer that programmer who did not consult too much, but who knows what they are doing.
What is your opinion and experience?
I would say that a developer who knows how to find the answers is better than one who has an overall good knowledge already. I find that intellisense is a good tool for finding answers, besides it is too much to remember all method names, arguments, overloads, etc.
I use memory to get me into the right general area (e.g. knowing which classes to use or at least which namespace they'll be in) and then often Intellisense/MSDN for the exact method name or arguments to use.
Having said that, Stack Overflow is improving my ability to code without any references (or even compilation) - I'm sure code will just work out of the box for me more often now than it used to. (I tend to post and then check the code works, add links to MSDN etc - assuming I'm reasonably confident in the approach.)
Someone knowing what resources are available, and how to find the answers, and how to effectively debug - these are qualities I look for now in prospective employees.
I used to consult my memory only, but two things have happened:
Class libraries have gotten larger, so has the number of languages available
The ratio of programming-related memory to personal-life-related memory has shifted away from code
Programming today is also eight times harder than it was when I started. I used to work on 8-bit machines, now I'm working on 64-bit ones. :)
I once was at a job interviewed with the CTO of a company. He asked a question based on a real life problem the company had a while back and solved. It was a multi step problem.
I was standing in front of a whiteboard working through my solution and struggling through a particular part, a part I would use google for before even attempting it, had I been tasked with solving this problem for real instead of for an interview. He asked me at that point, "would you do anything different if this wasn't an interview question." I responded, "Yes. I would exhaust all possibilities of using a third party component for this part of the task and look up the solution, because it is a well defined problem thats been solved several times." There was a bit more discussion where I justified my answer, explained exactly what I would research, and I solved some other parts of the question. In the end I was offered and accepted the job, partly because of knowing how to find out what I didn't know.
Being able to use references is as important as being able to code from memory. Obviously, if you are a one language shop, and want people proficient in that language,the person should be able to write a complete hello world app in notepad. Interview problems should focus on small problems, and one should not worry about small syntax errors. This is why a whiteboard is the best IDE for interview questions.
Unless you demand all your coders use notepad and don't give them internet access, don't be as concerned by the syntax. If you do sit them down in front of a computer, worry about the finished product as well as the technique used to get there.
I'm a PHP programmer in my early 30's. I rely on PHP's excellent documentation, for several reasons:
Programming concepts don't change. If I know what my object models are and how I want to manipulate data, then there's dozens of ways to implement the details. The details are important, but a better grasp of the design and structure is more important
PHP has notoriously inconsistent functions. One string function might use ($needle,$haystack) as parameters, and another might use ($haystack,$needle). Trying to keep them straight isn't worth the hassle when you can just type php.net/function_name and get the reference.
I don't rely on intellisense, simply because I haven't found a decent IDE for PHP that does it well. Eclipse is ok, but it's not fantastic. Netbeans gives me 'PHPDoc not found' for all the built-in PHP functions whenever I install it. There's nothing that I've found so far that beats out the documentation.
The bottom line is that the ability to memorize functions isn't indicative of coding ability. Obviously there's a key set of basic functions that a good programmer will know just from extensive usage over time, but I wouldn't base a hiring decision on whether someone knows substr_replace vs. str_replace from memory.
Because I've read either the documentation, or articles, or a book on a subject, the things I learn on a topic are organized. The result is that, if I can't bring something up from memory, I can probably find it quickly through IntelliSense or the Object Browser.
Worse come to worst, I can pick up the book again; something these youngsters are not being taught to do.
John Saunders
Age 51
Pretty much Google + Old Projects + my memory (of course)
References will not solve your problems though, its only for the nuts and bolts, the higher level of problem solving is the actual "programming" part IMHO.
I tend to use Intellisense and Resharper much more than I used to before, but this has helped my overall productivity. If I can get the idea of how I want to solve something and then use tools to get the more boring parts like class names and function signatures, why shouldn't I use the tools I have? I feel relieved that Jon Skeet has a similar approach it seems.
I rely on my bookmarks and books... and my ability to use them effectively. I have multiple books above my desk, including a copy of the ISO C90 standard. Moreover, I use Xmarks to have access to my bookmarks wherever I go. Sometimes, I make a pdf out of a particular page and upload it to my web-site if it is important enough.
Sometimes the information provided by the resources I use makes its way into my terrible memory... maybe.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm at a stage where I am forced to learn Lua, so do you have any suggestions on how I do this? I don't have a lot of experience with any other scripting languages than PHP.
So, some suggestions on "head start Lua"-pages?
EDIT
As an addition to the wonderful tutorial pages, could you please suggest any "programs" I could make that will help me learn Lua? Imagine I would want to learn Pointers in C++, I'd make a Linked List. I want to touch the basics in Lua but meanwhile be open to pretty advanced stuff.
First of all work your way through the Programming in Lua, it should take you a day or two to get the gist of Lua.
However I can tell you right away on your first time through ignore coroutines and metatables, they are very powerful, but take a while to grasp. First learn the syntax, scoping (same as PHP luckily for you) and the standard libraries.
After that go back to coroutines and metatables, read them try them and by the third time through you might get it. Unless you have a very good CS background these are complex topics
Edit: The book is free online == website. Besides it is the best tutorial out there on Lua, everyone learns Lua with it.
Also: If you're purpose is Lua for World of Warcraft (probably not but just in case) you can check out this tutorial
And: Here is a tips and tricks thread on StackOverflow, might help give you some ideas of what to expect from Lua
Suggested Programs/Exercises:
Since you're initially looking at Lua for web development try to understand and improve the Data Description example in PIL. It'll give you a few good ideas and a nice feel for the power or Lua.
Then you might want to try out playing with the Data Structures chapter, although Lua has a single complex data-type, the Table, that chapter will show you Lua-like ways to make a table do anything you need.
Finally once you begin to grok metatables you should design a class system (yes with Lua you decide how your class system works). I'm sure everyone that knows Lua has made a dozen class systems, a good chapter to get you started on a class system is Object-Oriented Programming
And if you got time and know C or something like that (C# and Java included) try extending an application with Lua, but that'll take a week or two to do
Funny to see all these elaborate lists (though they are certainly correct). Back in 2002, I read about the first 20+ pages of the Lua reference manual, and started using it. It really is that simple. Lua (and ANSI C) are of the few languages that really fit in one's mind all at once - and stay there. For the others, at least I need to constantly do some relearning.
Be aware that getting to think in Lua will take time. I think mine was 6 months or so. When coming from C/C++, we tend to solve problems in certain ways. Lua might offer better means (i.e. via use of tables) but it takes a while to start seeing those. This transition to a higher abstraction level is similar to the Assembler->C shift in the 1980's. Many people still coded a while in C as if it only were a portable assembler.
There is also a large body of projects related to Lua at LuaForge.
If you happen to use Windows as your day-to-day platform, then I would recommend getting the Lua for Windows package as a nice starting point. It includes a wide array of useful modules all prebuilt and installed together with the Lua interpreter.
After your first pass through PiL and the reference manual, you will want to read Lua Programming Gems which is currently only available in a paper edition.
<plug> Do consider buying the books through the associate links at Lua's books page or LuaForge to support the projects. </plug>
Edit: As for ideas for programming projects where Lua is suited, look for problems where the table provides leverage. Tables are central to Lua, since even the global variables are just fields in a table. Tables can be indexed by values of any data type except nil, but have an especially efficient implementation if used as arrays.
One quirk that trips up people coming from a C-like background is that all things in Lua are naturally indexed starting from 1. Strings are indexed from 1, arrays start at 1, etc. Don't worry about it too much, there is nothing wrong with using a[0], but the length of the array given by #a is defined assuming that the array began with a[1].
Another quirk is that functions don't really have names. They are first class values that are usually stored in some variable that has a name. Syntax sugar makes it look like they have names, but that is just a convenience.
Metatables are a particularly Lua-ish feature of tables (and other types, but that is a really advanced topic) that are the basis for most of the schemes for doing object-oriented things in Lua.
Closures and true tail calls are other features of Lua that aren't often found in small scripting languages that can really make some idioms easy to implement.
In addition to the suggestions above, there's also the Lua wiki which is well worth a browse. There are a tremendous number of code snippets and small recipes there which can be useful.
I wrote a short quick-start guide to Lua for people using it on a project I was working on.
If you are familiar with other scripting languages it may get you up and running quickly.
The docs on Lua.org are very good and should cover most everything else you need. Lua is a pretty small language and can be learned fairly quickly.
This is a pretty general recommendation, but if you want to get started in a new programming language as a software engineer, it's fun to start doing the problems found at Project Euler in your new programming language. I've been doing this with Python recently and found it to be inspiring and bring a lot of enthusiasm to the coding.
You could install World of Warcraft and make a mod for that (it uses Lua). Actually that's probably a bad idea.
Maybe try to integrate Lua into a .NET application (assuming you are a C# programmer) and do something 'fun' with it:
Using Lua with C#
Or just browse lua.org